Re: [binaryXML-30] Binary XML problem statement.

Elliotte Rusty Harold wrote:

> The problem is that this so-called binary XML may save you time, but it 
> pollutes the space for the rest of us. Maybe it's a net-gain for your 
> project. It's a net loss for the community, though.

I'll assume that this issue -- whether offering a choice of alternative 
serializations would have a negative effect on the Web community as a whole 
-- is in-scope for the TAG so I will respond here. If a TAG member requests 
or if this gets out of hand, we can move it to xml-dev.

I'm curious as to the reasoning behind the assertion that this would 
"pollute the space for the rest of us."  I don't see how an architecture in 
which XML 1.0 syntax is the default serialization and MUST be supported by 
any processor claiming to handle "XML", but allows alternative standard 
serializations to be negotiated, would have negative consequences for those 
who prefer to stick with the default.  One downside, I suppose,  might be 
that a small player (individual, open source community, small company) 
might be forced by market/hype pressures to devote resources to the support 
of formats it has no use for.  A similar argument is made against the 
"pollution" of the XML standards space by XSDL datatypes, the PSVI, etc.  
But the "binary XML" situation seems very much the opposite:  baking 
datatypes, the PSVI, etc. into the core of standards such as XPath 2 and 
XQuery  is saying "one size really DOES fit all, learn to like it."  The 
alternative serializations architecture says "one size does not fit all, 
use what fits your needs."

Another downside is that there would be a bunch of data out there 
purporting to be "XML" (in some sense) that older or text-specialized tools 
can't handle.  True enough, but that would be equally true if the "binary 
XML" people fork off.  The raw data would be equally unparseable, but in a 
"one XML, multiple syntaxes" architecture it could still be processed 
*after parsing* with XPath/XQuery, XSLT, DOM/JDOM/etc., validated with 
Infoset-bases schema definition languages, and so on.  That keeps diverse 
communities operating within a common framework, if not a common syntax.

Nevertheless, I agree that this raises an important point that IMHO the TAG 
should address: are the benefits of keeping diverse communities of "XML" 
users under a single roof worth the crowding, jostling, and tensions that 
inevitably ensue... or do the benefits of one-and-only-one syntax outweigh 
the benefits of common processing models, tools, and APIs while allowing
multiple syntaxes optimized for specific needs.

Wearing my W3C stakeholder hat I strongly prefer the "big crowded shelter".
Nevertheless, I realize that some TAG members feel strongly on this subject
and I would respect a W3C leadership decision to just let forking happen if 
it's gonna happen.

[Not by any stretch of the imagination speaking for my employer or any WG's 
I'm associated with!!!]

-- 
Mike Champion

Received on Thursday, 20 February 2003 11:30:00 UTC