I've mentioned in the past why I think XML 1.1 was a bad idea in my post XML 1.1: The W3C Gets It Wrong. It seems at least one W3C working group, the XML Protocols working group to be exact, has now realized why XML 1.1 is a bad idea a few months later. Mark Nottingham recently posted a message to the W3C Technical Architecture Group's mailing list entitled Deployment and Support of XML 1.1 where he writes

In the Working Group's view, this highlights a growing misalignment in
the XML architecture. Until the advent of XML 1.1, XML 1.0 was a single
point of constraint in the XML stack, with all of the benefits (e.g.,
interoperability, simplicity) that implies. Because XML 1.1 has
introduced variability where before there was only one choice, other
standards now need to explicitly identify what versions of XML they are
compatible with. This may lead to a chicken-and-egg problem; until
there is a complete stack of XML 1.1-capable standards available, it is
problematic to use it.

Furthermore, XML-based applications will likewise need to identify
their capabilities and constraints; unfortunately, there is no
consistent way to do this in the Web architecture (e.g., RFC3023 does
not provide a means of specifying XML versions in media types).

As I mentioned in my previous post about the topic, XML 1.1 hurts the interoperability story of XML which is one of the major reasons of using it in the first place. Unfortunately, the cat is already out of the bag, all we can do now is try to contain or avoid it without getting our eyes clawed out. I tend to agree with my coworker Michael Rys, the day XML 1.1 became a W3C recommendation was a day of mourning.


Tuesday, May 25, 2004 6:47:48 PM (GMT Daylight Time, UTC+01:00)
Are you saying that we should never have XML 2.0 in the future?
What if HTML would have never evolved from 1.0?
Or Schemas, or CSS, or XSLT ?

Sooner or later there will be a new version and unfortunately this would have happened anyway.

Nobody designed futureproof applications and now it is causing problems?

While XML 1.1 brings virtually nothing to the table, the fact that applications don't understand anything other than 1.0 is a great mistake.

Too bad for the short sighted, too bad.
Tuesday, May 25, 2004 7:03:49 PM (GMT Daylight Time, UTC+01:00)
I have very mixed feelings about XMl 1.1. On one hand I like the closer alignment with Unicode (making XML use it by reference rather than by value, more or less). I think the NEL issue is actually important; Michael Rhys says it "could have been solved by the IBM mainframe by mapping NEL to a whitespace character." Uhh, Unicode says that NEL *is* a whitespace line terminator, why should XML treat it as anything else? It's clearly a bug in XML 1.0, why not fix it sooner rather than later? As for the implication that big bad IBM can afford to hack around this, just think of how y'all in the Hive-Mind react to similar suggestions that Bill G. use a few of his spare billions to clean up various messes that Windows has created .... :-)

But you're absolutely right -- the cost relative to benefit of XMl 1.1 is pretty high. Likewise, allowing all the binary codepoints besides 0x0000 is just pointless, I aggree with Michael.

But what is to be done? Never version XML until something truly important needs to be done? The costs of that will be so high that there will be a temptation to dump XML altogether, or maybe to do with XML what XML did with SGML -- maintain sortof a conceptual compatibility, but not real interoperability except with a lot of effort.

So, I see XML 1.1 as sortof an experiment in whether it can be gracefully versioned, and whether the world can adopt to different versions without excessive pain. If the pain really is great, it should be quietly forgotten, by the world if not the W3C. Still, at least the Xerces people are saying that this is a done deal, ready to use (with the appropriate version checks), very little pain. We shall see, I guess, whether this REALLY inhibits interoperability any worse that all the other stuff out there does -- the different encodings, the wellformed/validating divide, the numerous ambiguities and monumental complexities in the Schema spec, etc.
Mike Champion
Tuesday, May 25, 2004 8:10:45 PM (GMT Daylight Time, UTC+01:00)
>Are you saying that we should never have XML 2.0 in the future?
>What if HTML would have never evolved from 1.0?
>Or Schemas, or CSS, or XSLT ?

No. XML is a foundation of a family of technologies that are aimed at guaranteeing interoperability across development platforms, programming languages and operating systems. You don't evolve such a system piecemeal or without consideration the stability of the system as a whole. XML 1.1 evolved the XML family of technologies in probably the worst way possible.

>While XML 1.1 brings virtually nothing to the table, the fact that applications don't understand anything other than 1.0 is a great mistake.

How do you suggest applications support future, non-existent standards without the benefit of a time machine? Given that XML 1.1 is backwards incompatible with XML 1.0, I fail to see how your argument has any merit. Does this also mean that C compilers written in 1990 that don't know how to compile C99 or the most recent version of C++ are making a "great mistake" because they don't support standards that were non-existent when they were created?

>Still, at least the Xerces people are saying that this is a done deal, ready to use (with the appropriate version checks), very little pain.

If all you are doing is writing a release early, release often XML parser supporting XML 1.1 can be done trivially. Maybe a few weeks of works, tops. I'm not sure any of the concerns myself or anyone else at Microsoft have voiced is that it would be difficult to implement an XML 1.1 parser or that it would take a long time to implement.
Tuesday, May 25, 2004 8:58:17 PM (GMT Daylight Time, UTC+01:00)
You use xml 1.1 as a scapegoat because of its weak impact, trying to sustain the ephemeral dream of a one-version format in order not to deal with versioning hell.

Unfortunately, versioning is part of evolution and you have to "futureproof" yourself foreseeing the changes that can affect your applications/standards if/when they occur.

Keep an eye open, not a closed mind.
Tuesday, May 25, 2004 9:07:10 PM (GMT Daylight Time, UTC+01:00)
Let's say, Dare, that in the near future we add capabilities to xml to represent arrays, lists, tables and other collections in xml in an easier way without the repetitive and expensive use of tags...

And suddenly the world applauds such idea for the great benefits it will bring to the data exchange arena...

How your applications/standards would embrace such new version?

Again, don't use xml 1.1 as a scapegoat. I know the benefit was minimum for the headache.

Versioning is needed, and sooner than later we will have to deal with it.
Tuesday, May 25, 2004 9:20:51 PM (GMT Daylight Time, UTC+01:00)
It seems you are not familiar with the problem domain and in addition you are ascribing qualities to my statements that I have not made.

Since it is clear you aren't bothering to read what I write, I have better things to do with my time then debate with a brick wall.

Have a nice day.
Comments are closed.