Nicolas Mailhot wrote:
There is *nothing* wrong with XML itself, if fact there are lots of very
good built-in properties in XML, the only thing a service description in
XML would need is strong style guidelines.
Yeah, that's what they always say. In the end, however, you know
a tree by it's fruit.
On some level you're right -- Bray's original XML specification is
one of the most beautiful technical documents I've read.
Namespaces are conceptually a good idea, but in real life they
require programmers to get a PhD in XML before they can use them.
If people consistenly use a tool incorrectly, it's a sign of either
conceptual flaws in the tool or an impeadance mismatch between the tool
and the applications. In most cases the second is the case with XML.
For instance, Cox says that some XML API's are bad but that someday
somebody might write a good one. The trouble is that it's hard to write
a good API for XML -- there's an impeadance mismatch between the vast
potentials of what you ~could~ do with XML and the tasks that
programmers actually need to do. For instance, they say you're never
supposed to write something like
# after outputting XML header
print <<END_XML;
<record>
<field1>$field1</field1>
<field2>$field2</field2>
</record>
END_XML
because you could easily bork it up and get output that isn't valid
XML. Now there are a hundred different ways you could do things
'properly' with the DOM API by creating DOM objects and combining them
until you've got a DOM tree in RAM, and then writing it out -- simiarly
you could do it in a SAX-like case. The trouble is that all of them are
much less obvious than the one above, where it's clear how to add
<field3> or make any other kind of change in the output text.
In real life, I've often spent the greater part of a day figuring
out how somebody is building an XML document (first figuring out the XML
API, and then all the cruft they built on top of it) in order to make a
simple change in the document that I could have made instantly had they
done it the way above... On the other hand, had they done it the way
above, I could have easily blown the system away by having a '<'
character in $field1.
On the other hand, it would be a challenge to create a difficult
API for
* Windows .ini files
* CSV files
* lisp s-expressions
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
