Live data from Hacker News

What's frustrating with XML?

stackoverflow.com

21–28 of 28 posts

Re: What's frustrating with XML?

#21
post #2

Namespaces are both the genius and stupidity of XML. The idea of being able to stitch different vocabularies together is genius. That said, I haven't seen a single XML toolchain that doesn't have some bug or, ahem, irregularity, in how namespaces are handled. XLinq comes pretty close to being correct though.

I agree that the concept of namespaces is brilliant, but very difficult to read in practice. The rules around the different ways to specify namespaces also seem unnecessarily complicated - I always need to review the XML schema spec, and spend a bit of time on it.

I feel they should be as simple as (eg) Java packages; but the problem has different parameters in Java: there's less chance of collisions in Java, because you're just writing one module; whereas one XML document can merge different sources - it's as if arbitrary Java modules, written by unknown people, were combined into the one file.

Re: What's frustrating with XML?

#22
post #20
post #12

Closed as subjective and argumentative. Darn, I wanted to pick a fight there. ;) Many of the really crappy aspects of XML have been thoroughly abstracted away by libraries. I'm of the opinion that you can only truly despise XML if you've tried to write a parser for it yourself. Examples of the issues: It requires arbitrary lookahead & backtracking. There is no canonical document encoding. (Support arbitrary character…

Could you explain the arbitrary lookahead and backtracking please? I thought UPA (unambiguous particle attribution - or "deterministic" for DTDs) avoided the need for backtracking... Or is it to do with entity references? I've found it simple to write XML parsers, but that's for a common (defacto?) subset, not the full spec.

Note that I was talking about parsing a stream of text into a DOM tree or SAX events, not parsing a DOM tree or SAX events into some second-order structure.

Lookahead: Your parser will need to read the entirety of a tag (from the '' or '/>') to know whether it is a start tag or a complete tag. I think my use of the word backtracking was a wee bit sloppy, although the above situation may cause it in some types of LL() parsers. http://www.antlr.org/wiki/display/ANTLR3/3.+LL%28*%29+Parsin...

(Another parsing gotcha: XML isn't even context free, since the start and end tags must match and, for a general parser, there's an infinite number of possible tags.)

Re: What's frustrating with XML?

#23
post #12

Closed as subjective and argumentative. Darn, I wanted to pick a fight there. ;) Many of the really crappy aspects of XML have been thoroughly abstracted away by libraries. I'm of the opinion that you can only truly despise XML if you've tried to write a parser for it yourself. Examples of the issues: It requires arbitrary lookahead & backtracking. There is no canonical document encoding. (Support arbitrary character…

> I'm of the opinion that you can only truly despise XML if you've tried to write a parser for it yourself. Or had to work with any of the utterly terrible xml dialects out there, which represents about 90% of them first and foremost xslt and xsd. Or had to deal with the various bugs in parsers, or with most people's (and software's) complete and utter inability to correctly deal with xml namespaces.

Strictly speaking, XML could be extremely well done and still have horrible horrible things done with it higher up in the layer cake. ;)

There's no surprise, though, that a shoddy foundation might encourage crappy houses.

Re: What's frustrating with XML?

#24
post #22
post #20

Earlier quoted context omitted.

Could you explain the arbitrary lookahead and backtracking please? I thought UPA (unambiguous particle attribution - or "deterministic" for DTDs) avoided the need for backtracking... Or is it to do with entity references? I've found it simple to write XML parsers, but that's for a common (defacto?) subset, not the full spec.

Note that I was talking about parsing a stream of text into a DOM tree or SAX events, not parsing a DOM tree or SAX events into some second-order structure. Lookahead: Your parser will need to read the entirety of a tag (from the ' ' or '/>') to know whether it is a start tag or a complete tag. I think my use of the word backtracking was a wee bit sloppy, although the above situation may cause it in some types of LL(…

OK, thanks, I see what you mean.

Re: What's frustrating with XML?

#25
post #12

Closed as subjective and argumentative. Darn, I wanted to pick a fight there. ;) Many of the really crappy aspects of XML have been thoroughly abstracted away by libraries. I'm of the opinion that you can only truly despise XML if you've tried to write a parser for it yourself. Examples of the issues: It requires arbitrary lookahead & backtracking. There is no canonical document encoding. (Support arbitrary character…

XML isn't bad in and of itself. It's just a powerful, neutral format. The problem with XML is that it allows so much abuse. I had to interface with a government system at some point. They shipped us a whole schema of custom elements such as "IsShipment" (for example) which extended bool to allow extra options. All this was clearly documented in the schema comments "You can use 'true', 'false', 'sortof', and 'mostly'.…

> XML isn't bad in and of itself.

I'm arguing that it is. Symptoms of badness: version 1.0 of the basic standard is on its 5th edition over ~8 years. Said standard is stupendously huge. Major security/crash & other bugs in pretty much every parser (https://www.cert.fi/en/reports/2009/vulnerability2009085.htm...) as of less than a year ago. XHTML's abandonment. In short, XML stinks and there's plenty of evidence out there that it does.

Please note that doesn't mean I would wish XML away. Widespread adoption, in and of itself, is a killer feature.

Re: What's frustrating with XML?

#26
post #6

Earlier quoted context omitted.

The biggest problem is that a namespace can be declared anywhere, so technically it's impossible to use a streaming reader unless you stream through the document twice. Also xlink and other ways of dynamically composing xml is too complicated.

I don't really get why, since you can't use a namespace before it's defined and namespaces are scoped. The only reason why you'd have to stream through twice is if you wanted a list of all namespaces in the document at the start of your parsing, and why would you want that (let alone care about it)?

It appears I was incorrect. Thank you. As I thought about it I couldn't recreate the issue I recalled having -- it may have resulted from using a buggy xml parser and/or a misunderstanding of the specification. But I should clarify, I am a huge proponent of namespaces -- I think they're great, I'd just prefer them to be declared at the start of the document.

Re: What's frustrating with XML?

#27
post #6

Earlier quoted context omitted.

I don't really get why, since you can't use a namespace before it's defined and namespaces are scoped. The only reason why you'd have to stream through twice is if you wanted a list of all namespaces in the document at the start of your parsing, and why would you want that (let alone care about it)?

It appears I was incorrect. Thank you. As I thought about it I couldn't recreate the issue I recalled having -- it may have resulted from using a buggy xml parser and/or a misunderstanding of the specification. But I should clarify, I am a huge proponent of namespaces -- I think they're great, I'd just prefer them to be declared at the start of the document.

> But I should clarify, I am a huge proponent of namespaces -- I think they're great

They're nice, but generally misimplemented, misunderstood and misused.

> I'd just prefer them to be declared at the start of the document.

I'm not sure why. It's nicer when you have to read the document yourself for sure (but then again, XML is rarely actually nice to read), but when mechanically processing it it shouldn't be relevant: just use each node as a (ns, name) pair where ns is the namespace's URI (not its alias) and name is the localname. In that case, what does early declaration bring to the equation?

Re: What's frustrating with XML?

#28
post #9
post #7

Earlier quoted context omitted.

... which reveals the real problem with namespaces, which is that "nobody" actually understands them. There really isn't that much to them, in my opinion, but every time I encounter them in the wild, they're never implemented correctly, with the variance ranging from really, really wrong to just sort of off. XMPP is the closest to correct, but they still screwed up in that a user's connection to an XMPP server is und…

> There really isn't that much to them, in my opinion, but every time I encounter them in the wild, they're never implemented correctly, with the variance ranging from really, really wrong to just sort of off. My biggest issue with namespaces is the dichotomy between namespace URLs and namespace prefixes, and most people not understanding that prefixes are actually aliases for the URLs. For that reason, I quite like…

Well, to be fair, the best parsers do handle it correctly. Frequently the binding logic in Perl or Python or whatever will then proceed to get it wrong! And if you've got anything more complicated than a straight C binding and it actually tries to do stuff for you, you can just forget about it working correctly.

When I say I'm still waiting to see the software that does it correctly, I mean like end-user-level software, not the parsers.

Post reply on HN