[
Lists Home |
Date Index |
Thread Index
]
Ronald Bourret wrote:
> This assumes that "XML" refers to the serialization format alone. For
> most of us, XML refers to the whole spectrum of things XML, from XQuery
> to XML Schemas to DOM trees. The fact is that binary XML seeks to
> exploit all of these things except the serialization format.
Not really. It varies from one binary XML proposal to the next, but many
subset XML by, for instance, removing the document type declaration and
DTDs. Others superset XML by allowing the presence of arbitrary binary
data including characters like null that are simply not legal in XML.
Even if we leave the serialization format aside (which basically means
we're leaving XML aside) these are still not XML.
> While there is a real worry about the balkanization of exchange formats,
> the reuse of common document models, query languages, schema languages,
> and so on seems to be Good Thing, as it allows all of these technologies
> to be reused.
Reuse of common document models, query languages, schema languages, and
so forth is good. However, if we have to warp them from their original
intended purpose of handling XML to fit models that don't have types on
attributes, or allow null character data, or the other weird things we
see off in the binary space, then they become more complex and less
useful. One of the nastiest problems that arises in practice is that
these tools begin creating and describing document that cannot possibly
be serialized as well-formed XML. The infoset is a particular offender
here, and its problems tend to infect downstream specifications. That's
why I'm much more comfortable working from real XML documents than some
abstract, infoset formulation.
> For me one of the most interesting posts to xml-dev in the recent past
> was the use of XPath in the UNIX find utility. On the one hand, this has
> nothing to do with XML. On the other hand, it's a pretty nice reuse of
> technology that came out of XML in a non-XML environment. It is
> particularly easy to imagine XML query languages being used in any
> number of such non-XML environments, especially when it is easy to
> define a simple, canonical mapping from those environments to XML, as
> was done in the find case.
A question raised in this case demonstrated very well the problem of
trying to fit XML tools into non-XML scenarios they were never designed
for. A Unix or Windows file name is not an XML name. How does this tool
handle file names that contain spaces? I never saw an answer, though
perhaps I just missed it. I don't think this question can be answered
without breaking either XPath or the file system. One has to be forced
to fit the other, and either way the result is brittle and ugly.
--
Elliotte Rusty Harold elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
|
