What's frustrating with XML?
stackoverflow.com
What's frustrating with XML?
1–10 of 28 posts
Re: What's frustrating with XML?
#2Namespaces 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.
Re: What's frustrating with XML?
#3Namespaces 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.
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.
Re: What's frustrating with XML?
#4Namespaces 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.
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'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.
Re: What's frustrating with XML?
#5Namespaces 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.
There is a type-system (and graph) encoding for JSON called JSYNC (http://jsync.org) which is compatible with YAML's model.
Re: What's frustrating with XML?
#6Namespaces 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.
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)?
Re: What's frustrating with XML?
#7Earlier 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)?
... 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 under one namespace, and a component is done under another, yet an packet with no namespace qualification is supposed to be treated as the same packet in both, despite being two different packets. (I would accept simply acknowledging that they are the same somewhere, but I've never found it.)
Some people use the namespaces in what appears to be a decorative manner. Some people mandate that the prefix be a certain thing works while doesn't, proving they're doing it wrong under the hood. Some things get it right with xmlns:*, but don't understand what the bare xmlns itself means, so they only trigger namespace logic if there's a colon in the tag. I've seen cases where the namespace is declared, then used out-of-scope like it's a global declaration or something. I'm still waiting to encounter the standard or software that actually uses them correctly. And despite this listing of wrong answers it really isn't that complicated....
Re: What's frustrating with XML?
#81. dtds
2. control characters
3. xml schema
4. ID elements other than xml:id
5. needs alternative data oriented syntax: document { element { "text" } }
6. document != fragment
7. everything soap
Re: What's frustrating with XML?
#9Earlier 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)?
... 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 Clark's notation for namespaces (which is used by ElementTree and LXML), it makes the relation between element and namespace much clearer. Shame you can't use it in XML documents or XPath queries.
Also, that the default namespace only applies to elements, not attributes. I kind-of understand why they did that, but it's still very annoying.
> Some people use the namespaces in what appears to be a decorative manner. Some people mandate that the prefix be a certain thing works while doesn't
Oh yeah. Isn't it maven or something, which does that? Or did? I know I encountered it once or twice and I was using ElementTree 1.2 at the time (the one that went into the Python stdlib... and still is) and it doesn't keep track of XML namespace aliases (or defaults for that matter, and doesn't let you set them short of hacking through the private and undocumented namespace map) so everything comes out as `ns0:foo`, `ns1:bar`, ... Perfectly valid, and then you have a retarded tool which doesn't actually understand namespaces (even though the example documents say you need a namespace spec) and want an element called `foo:bar` and not "the element `bar` in the namespace http://foo.com.
> Some things get it right with xmlns:* , but don't understand what the bare xmlns itself means, so they only trigger namespace logic if there's a colon in the tag.
When that happens, somebody ought to get shot. Default namespaces are one of the most basic parts of namespaces (and it's not that hard to parse, though production might be a different issue).
> I'm still waiting to encounter the standard or software that actually uses them correctly.
libxml2 tended to work quite well in my experience (mostly though lxml), though I don't doubt I just missed its bugs.
edit: damn it, is there no way to escape those damn asterisks in yc?
Re: What's frustrating with XML?
#10"We're an XML shop": who says that?