OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] How simple is simple enough? - was Re: [xml-dev] xml2.0 -

[ Lists Home | Date Index | Thread Index ]

Michael Champion wrote:

>  The existence proof of correct, efficient XML parsers is true only in
> a somewhat academic sense.   XML's "efficiency" is not exactly its big
> selling point these days, as Robin Berjon frequently reminds us. 

Robin and others have never made a convincing case here, just a lot of 
hand waving and pointing to a few corner cases in areas XML wasn't 
designed to handle, and attempts to use that as justification to break 
XML for the millions of use cases where people are productively and 
efficiently using it every day. If anyone really wants to reopen that 
permathread, please change the subject line.

> Likewise, obviously there is a community of people who understand XML
> as specified, can write tools easily and well-formed XML without
> thinking about it.  At least for me, that's not the target audience.
> Out there in the real world are legions of people who still get
> confused about the oddities in XML and re-invent ideas to make it
> easier that were discussed to death in the WG and xml-dev over the
> years.  (http://www.tjansen.de/blogen/2003/12/10-things-i-hate-about-xml.html
> was brought to my  attention recently, 

This person doesn't strike me as at all confused about XML. Rather he 
knows exactly what he's talking about. He just doesn't like it. I'd put 
him in the simplified XML skunkworks camp. I don't really disagree with 
much of what he says. The question is whether it's worth breaking XML by 
introducing yet another incompatible version.  My gut feeling is that it 
isn't. There's ugliness in XML, but it's not so ugly or so problematic 
that it's worth revising. The cure would be worse than the disease.

> as was
> http://geekswithblogs.net/rebelgeekz/archive/2004/02/28/2433.aspx  --
> which takes an opposite position from Elliotte Harold on the
> user-friendliness of end tags).

This person's simply wrong. If he actually tried to write XML without 
names in end-tags he'd rapidly discover why they're there. It's just too 
damn hard to tell which start-tag </> ends. Named end-tags do make 
authoring XML easier, whether people believe they do or not. (sort of 
like how menus are faster than menu key shortcuts, even though most 
people believe the opposite.)

> I don't necessarily agree that anyone who understands formal grammars
> at the CS undergrad level should be able to write an XML parser.  On
> the other hand there is something to be said for making it less
> necessary to know a whole lot of folklore about why things are the way
> they are (but are not specified in the formal grammar) in order to
> write interoperable software. I once watched someone who knew a lot of
> CS but little XML try to write an XML parser ... it was not a pretty
> sight or successful project. I get a fair number of inquiries from
> users or developers about murky questions of XML syntax that are just
> not obvious from the spec but well known in the folklore. (I would be
> up a creek without Tim Bray's Annotated XML, let me tell you!). 

Perhaps what we need, then, is not XML 2.0 but rather XML 1.0, fourth 
edition, that emphasizes readability and explicitly calls out and 
explains with examples the corner cases? Or maybe we should have an 
official W3C XML Primer instead, sort of like the W3C XML Schema Primer? 
  I tend to doubt, though, that any XML 2.0 spec would be any more 
comprehensible than the current third edition XML 1.0 spec. Most W3C 
specifications are not written for end-users.

> Still, whether or not there is an XML 2.0, there is almost certainly
> going to be a withering away of the under-used legacy stuff and a move
> toward tools that implicitly deprecate it or at least relegate it to
> the "difficult things must be possible" corner.   I'm sure this is
> anathema on this list, but hand-authored XML is just not a mainstream
> use case anymore, 

I disagree completely. Hand-authored XML is critical to its acceptance. 
Even when the XML is machine generated, hand-authoring is necessary to 
design and debug formats. Making hand authoring more difficult would 
significantly reduce the usefulness and ubiquity of XML.

> and it's going to be harder and harder to make a
> business case for keeping around the stuff (half the productions, I'll
> guess?) that exist just to facilitate it.   In the long run, what the
> Pointy Haired Bosses find compelling is more persuasive than what the
> experts find compelling, I'm afraid.

The business case is trivial. XML exists. It works. It's cheap. It's 
easy. We're familiar with it. The case that needs to be made is by those 
who want to throw this away and start over. What compelling benefits 
will they provide that are worth the resulting disruption? So far I 
haven't heard any. Making parsers easier to write doesn't help when 
there are plenty of good enough parsers already.

Of course, there are companies and individuals with a vested interest in 
upsetting the stable, well-tested apple cart so they can sell more 
products. Hell, I'm one of them. XML book sales are in the toilet. Maybe 
XML 2.0 would help juice them again. XML 2.0 might be good for 
Microsoft, and it might be be good for Expway, and it might be good for 
Elliotte Rusty Harold, but it's not going to be good for the vast number 
of non-XML businesses that just want to get their work done. For them, a 
new version of XML is another random fluctuation in the tech world that 
they have to adapt to for no particular reason. And to the extent XML is 
used for interchange, they can't just ignore it like they can new 
versions of some other products.

> Of course, given XML's acceptance today  this move toward
> simplification  will take awhile to play out wiithout causing
> excessive disruption.  (My own uber-not-so-pointy haired boss just
> drove another stake in the ground for XML as the basis of interop -
> http://www.microsoft.com/mscorp/execmail/2005/02-03interoperability.asp)

1. I don't believe your pointy haired boss actually wrote this article. 
It reads like something out of the mouth of a marketing flack, not 
something uber-Bill would say.

2. Regardless of who actually wrote this, it's always amusing to hear 
Microsoft spout the virtues of interoperability, sort of like listening 
to Republican presidents express their concern for the environment; but 
it's really, really hard to take seriously.

> Or as he puts it less formally "W3C determines who is happy with XML
> the way it is and who is unhappy. Then they define a shiny new XML
> which will make all the happy people unhappy, but make all the unhappy
> people happy."   It's been 7 years next Thursday, about time to think
> about that 10-year review, and maybe time to screw up the courage to
> make some old-timers unhappy :-)

Screw the old-timers. We're a trivially small part of the XML universe, 
just like the trivial number of people who actually write XML parsers. 
But do remember the huge number of people who actively and productively 
use XML on a daily basis, whether they know it or not, and who will be 
massively inconvenienced by the mere existence of a new version when the 
old one serves their needs just fine. The XML 1.1 debacle made it clear 
that the W3C has no institutional recognition for the value of stability 
for stability's sake. They are categorically unable to see that a flawed 
but stable spec can be preferable to a constantly improving spec. Make 
no mistake: XML 1.0/1.1 is flawed. However, the flaws are small and 
easily ignored or worked around. There is no problem with XML 1.0 that's 
big enough to justify any backwards or forwards incompatible revision.

Elliotte Rusty Harold  elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS