Lists Home |
Date Index |
Bullard, Claude L (Len) wrote:
> Ok. Any parties interested in posting their favorite five bad
> problems with XML in order here? I wonder what the consensus is on
> the top two.
Only Five? Darn. I cannot squeeze it to less than six :-) Here they are:
1) The lack of sane, simple roundtrippability. I read in some XML, I
write it straight back out again. I loose stuff on the way. R u nuts?
And you call this a machine processible data format:-) My proposal for
fixing this zit on the face of progress is here :
http://sdec.reach.ie/rigs/rig0002. Yes I have read XML canonicalisation
spec and the exclusive one and the schema aware one. I rest my case.
2) Namespaces - specifically defaulting an the "declare 'em anywhere you
like buddy" aspects. Again, I've taken a shot at limiting the damage
these puppies have done. My effort is here:
3) No same, simple pull based XPath 1.0 subset.
4) W3C XML Schema - pretty much everything about it.
5) Doctype. We should have left assertions about schema compliance (and
consequently the entire idea of an embedded document type declaration
subset) on the clipping room floor. This causes endless grief when, for
example, you wish to do a WF parse and don't have the asserted DTD to
hand. Also, grief ensues when you are writing out a instance and need to
reflect whatever doctype it had on the input side, but it needs to come
after - not before - the XML declaration ... etc.
6) Fuzzyness over the use of terms like "XML parser" and "XML Editor"
and "XML aware" and "XML compliant". If product X does not do Unicode,
chokes on DTD subsets, casefold element type names, scatalogizes
whitespace or whatever then is it okay to call it an XML parser or XML
Editor?. We shouldn't have to read the fine print in the release notes
of a product to find out what the thing doesn't do "yet". Commercial
concerns have taken advantage of this fuzzyness to label all sorts of
things "XML-based" and "XML compliant" when they are not. Interop
problems are the inevitable result.