Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] A call for XML 1.1
 Tim Bray wrote: > It is not clear that rules could ever be written. The current syntax > exposes (a) whether a DTD is available and (b) whether it will change > the infoset. Newbies coming to XML inevitably expect a choice "DTDs" or "no-DTDs" but instead are faced with "valid" and "well-formed" and "standalone". We should admit that the newbies are correct. As XLink and xml:base and xml:include and XML Schemas come online (for better or worse) the current situation will move from regretable to one where we are guaranteeing that vendors can use implementation features to lock out other vendors: if Microsoft implements xml:include but not xml:base for example. XML did not adopt the SGML declaration and did not put in some kind of "features manifest" precisely to prevent fragmentation of implementations. But this is what seems to have happened; the rise of these horrible little mini-specs like xml:base and xml:include will just make things worse. This kind of low-level layering represents a potential disaster for XML as a common broadly-based format. I think XML should be bent to fit in with people's expectations: it would be better to get rid of the standalone concept and limit XML to 2 flavours only: * Basic XML 1.1: No markup declarations, but with namespace, xml:base and xml:include support * DTD-Valid XML 1.1: Markup declarations, all entities dereferenced, valid. Support of namespaces, xml:base, xml:include and external sourcing of identifiers (i.e. CATALOG). This is not a call for minimalism. The status quo in the XML Spec was probably a wise decision, in that it made parser-writers take DTDs and entities seriously and gave writers an amount of flexibility. But soon we will be faced with lots more permutations, all legitimate and non-interoperable. I would prefer for xml:base and xml:include to go away, but it seems that W3C will push ahead with them. So it is time for action. I fear that the advent of SML and Common XML will only legitimize more fragmentation; like a drowning man knocking a lifesaver unconshus. "Basic XML 1.1" would in fact be more complicated than the base-level XML 1.0 as it was originally released (no DTD parsing, but xml:include replaces entities and the namespace and xml:base support would be needed too.) But it would seem more simpler for newbies and put XML back on track. While I do not agree that there is a groundswell of opinion for a minimal XML, I have taught XML classes to hundreds of people now, and the consistent expectation is that there should be two modes: declarations or no declarations. I hope W3C does not release xml:base and xml:include without addressing also how they intend to prevent fragmentation. I call on W3C to reformulate XML along the lines I suggest, and reissue XML 1.1 with the errata currently being worked on and with xml:include and xml:base. And I also call on them to keep xml:base and xml:include in CR until they can be folded into an XML 1.1. I would say that this problem is far more apparant over here in Asia than in the West. This is because we have so many XML processors which give only UTF-8 or UTF-16 support: this has the amazing effect of guaranteeing both interoperability and un-useability! So already over here we already experience this fragmentation (developers: please do not support or use XML parsers or XSL tools which do not support a good range of encodings!!!!) which can only be made worse by all this too-thin layering. XML's very purpose is as a common exchange format. Whether or not the current situation is acceptable or not, the new specifications coming up will, if not managed better, Balkanize XML. This is a situation which I do not expect many large companies will kick up much fuss about this in the W3C: those companies who are not interested in using the new extensions for example, or those companies who are in some position to dominate the market. I am all for plurality and competition; but only in a managable framework. This either requires some "features manifest" system or a rationalization of XML. I suggest that a rationalization would meet user's legitimate expectations better, and require less change to the XML Spec. (A trouble with a features manifest PI is that one then fragments XML processors that understand Features Manifests and those that don't. ) Rick Jelliffe *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ *************************************************************************** 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
