[
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!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
|
