Re: HTML and XML

Bijan Parsia wrote:
> My point, which I think you agree with, is that well formed XML is 
> non-trivial to produce and (faithfully) transmit in some fairly general 
> cases. (E.g., it requires fairly specific, dedicated training, including 
> on tooling.) It was not clear to me that this thread was willing to 
> acknowledge this fact. Similarly, writing programs that output well 
> formed XML is non-trivial under a wide variety of not uncommon 
> circumstances. (E.g., blog feeds.)

I would not disagree with those points.

> If we agree on this fact, then what remains is what conclusions to draw 
> from it and what actions are reasonable. One conclusion one might draw 
> is that the costs are worth the benefits. Another might be that there 
> are some things one might do to mitigate the costs. Another would be 
> that the costs are essential to the benefits. (Which I think is your view.)

My view is B and C. I think we can widely mitigate this with better 
tools and no changes at the core. I think we need to encourage and train 
users to use better tools and libraries such as XPath, XOM, and E4X in 
preference to badly designed tools and libraries such as DOM and JAXP 
(specifically the non-standard parts of JAXP).

The cause of this problem, IMNSHO, is that the tools and APIs have 
largely been designed by non-XML-experts who make the same mistakes over 
and over again. I do not consider it an anti-pattern that expertise is 
necessary to create tools for non-expert users. The tools designed by 
XML experts such as SAX, XPath, XQuery, and XSLT I find to be quite 
usable, practical, and functional. The tools designed by non-experts I 
find to be atrocious. This includes most libraries bundled with 
languages such as PHP, Java, and Ruby. The programmers who invented and 
developed these languages simply did not have the necessary expertise in 
XML to develop a correct library, though certainly they were experts in 
other areas.

There's nothing unique about XML, in this respect by the way. For 
example, I'm sure SQL experts could find fault with SQL tools and 
libraries designed by non-SQL experts. I know professional photographers 
find fault with photography software designed by professional 
programmers instead of professional photographers. No one person can be 
an expert in all fields. However, the reason non-experts use tools and 
libraries instead of coding everything by hand is precisely so they 
don't have to be experts. They are relying on the expertise and specific 
domain knowledge embedded in the tool or library to give them the power 
of an expert without being an expert. This breaks down when the person 
or people who built the tool are not experts.

I do not, however, see any evidence that a change in the parsing model 
or the core syntax of XML would be in any way helpful. It would add 
additional complexity. It would make the situation worse, not better. 
Just maybe a radical simplification of XML along the lines of Tim Bray's 
XML-Skunkworks might be helpful, but even there I'm not sure it's worth 
the cost of transition.

-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA

Received on Tuesday, 17 February 2009 16:54:14 UTC