OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Re: Where does the "nothing left but toolkits" mythcome fr

[ 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!


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS