4 ms·

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

by terra_t 16y 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.

dantheman 16y 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_t 16y 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.
- masklinn 16y 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)?
  - jerf 16y ago
    ... 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 <iq> 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 <x:tag xmlns:x="thing"> works while <y:tag xmlns:y="thing"> 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....
    - masklinn 16y ago
      > 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 <x:tag xmlns:x="thing"> works while <y:tag xmlns:y="thing"> 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 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?
      - jerf 16y ago
        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.
  - dantheman 16y ago
    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.
    - masklinn 16y ago
      > 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?
cce 16y ago
There is a type-system (and graph) encoding for JSON called JSYNC (http://jsync.org http://jsync.org) which is compatible with YAML's model.
10ren 16y 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.

by terra_t 16y ago

dantheman 16y 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_t 16y 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.
masklinn 16y 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)?
- jerf 16y ago
  ... 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 <iq> 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 <x:tag xmlns:x="thing"> works while <y:tag xmlns:y="thing"> 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....
  - masklinn 16y ago
    > 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 <x:tag xmlns:x="thing"> works while <y:tag xmlns:y="thing"> 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 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?
    - jerf 16y ago
      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.
- dantheman 16y ago
  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.
  - masklinn 16y ago
    > 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?

cce 16y ago

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

10ren 16y 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.