- From: Mike Champion <mike.champion@softwareag-usa.com>
- Date: Thu, 20 Feb 2003 11:29:14 -0500
- To: www-tag@w3.org
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