What's frustrating with XML?

http://stackoverflow.com/questions/3536893/whats-frustrating-with-xml

by julien • 16 years ago

28 25 16 years ago

terra_t2• 16 years ago

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.

dantheman2• 16 years ago

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.

terra_t2• 16 years ago

I've been thinking about a way to represent RDF namespaces in JSON... I've seen RDF-in-JSON proposals that I don't like, because they involve whole URLs as keys, and I'm afraid that wouldn't work well in every JSON stack that's out there.

masklinn4• 16 years ago

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)?

cce• 16 years ago

There is a type-system (and graph) encoding for JSON called JSYNC (http://jsync.org) which is compatible with YAML's model.

10ren4• 16 years ago

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.

wooby• 16 years ago

"We're an XML shop": who says that?

contextfree• 16 years ago

It convinced a generation of framework designers not to bother designing a decent concrete syntax for their domain-specific languages. When the framework is small and/or its developers probably couldn't hire a good language person anyway, this might be for the best, but it's a shame when a huge, well-funded and otherwise fairly well designed beast like WPF/Silverlight/XAML is trapped behind tasteless syntax.

On a deeper level, the element/attribute distinction unnecessarily mucks up the data model, but I'm not sure how big a problem that is in practice.

crux_4• 16 years ago

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 encoding for content: great idea! Support arbitrary encoding for the metadata/XML itself: The opposite of a great idea.) Entity references: need I say more?

There's a reason this sort of thing keeps coming up: http://voices.washingtonpost.com/securityfix/2009/08/researc...

XML as it would be in an ideal world would be (a) simple and (b) unambiguous; it fails both.

All that said, there's a huge benefit in the whole world arriving at a somewhat standard way of doing things, and a lot of that benefit remains even if the standard itself really sucks.

masklinn4• 16 years ago

> 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.

crux_4• 16 years ago

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.

sofuture• 16 years ago

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'." So we go to validate the data.... and it doesn't validate. Against their schema. Because they didn't extend bool, they just said they did in the comments. When we got back in touch with them, we realized that they had no clue that the stuff not in comments mattered. As far as they knew, XML was just text, and they had clearly specified how it was to be interpreted (in English).

10ren4• 16 years ago

You make me wonder if the hate is partly due to XML being used in integration, and integration is difficult and problematic, and vulnerable to all kinds of communication problems.

And if JSON tends to be used where integration isn't very challenging (eg. you control both ends, and the data is fairly regular and simple; or one end is entirely determined by the other); that is, where schemas aren't needed.

crux_4• 16 years ago

> 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.

10ren4• 16 years ago

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.

crux_4• 16 years ago

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 '<' to 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.)

Reply

dstein• 16 years ago

The problem with JSON is that isn't very useful by itself because you always have to encode and decode it, and then analyze the structure to do something with the data. It works better as part of a protocol, not as a native data format.

If you convert your JSON data to XML (assuming it is structured in a way that makes it lossless) you have a whole lot more useful tools at your disposal.

Reply

arethuza• 16 years ago

People do seem to like abusing attributes... A surprising number of systems seem to rely on embedding entire XML documents in attributes within other documents.

Reply

joe_the_user• 16 years ago

The most horrible XML encoding I've encountered recently was the Gnome/Kde Xdg desktop menu system.

Rather than encode what menu item is in what pseudo-folder, it encodes every change made to the menu system as a diff and expects the applications will piece these together -- and the libraries that parse this monstrosity all huffily say "this code is NOT stable...".

http://standards.freedesktop.org/desktop-entry-spec/latest/

Of course, this isn't so much XML's fault as the fault of the folks who kludged together this monstrosity. This shows, however, how XML is more or less a tool for knitting together two or more generally poorly-specified encodings. The good is that these might be somewhat better inside XML than running about wild but the bad is it lets them continue to exist all. See Microsoft's Office XML "standard".

Reply

What's frustrating with XML?

Related Stories