xml-dev - A call for XML 1.1

[Rick JELLIFFE <ricko@geotempo.com>]

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@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************