3 ms·

The funny thing is, XML namespaces are not that complicated. They're the solution I would come up with given the same task. They're defined simply thus: -- D

The funny thing is, XML namespaces are not that complicated. They're the solution I would come up with given the same task. They're defined simply thus: -- Data model -- 1. Every tag and attribute is optionally namespaced by a URI. (Tags usually are, attributes usually are not.) 2. The meaning of a non-namespaced attribute is defined by the tag to which it's applied. 3. The meaning of a non-namespaced tag is defined by the application. -- Serialization -- 4. To save space in the textual representation of XML, namespaces are (necessarily) referenced by user-defined aliases. 5. To save even more space, a default namespace may be (and usually is) defined for use by tags (but not attributes). 6. Alias definitions live in opening tags, and are scoped to the tag itself and all its children. They are of the form xmlns:{alias}="{namespace}", or xmlns="{namespace}" for the default namespace. 7. Tag and attribute names are prefixed with an alias to indicate that they live in that namespace: {alias}:{tag/attribute name} 8. If a tag name is not prefixed with an alias, it lives in the default namespace (if any). 9. If an attribute name is not prefixed with an alias, it is not namespaced. 10. The aliases generally have no semantic meaning, but there are wacky exceptions (e.g. XML Schema). EDIT, forgot: 11. The "xml" namespace is reserved and predefined as 'http://www.w3.org/XML/1998/namespace' http://www.w3.org/XML/1998/namespace'.

jerf 10y ago
I realized I ought to write it up too, so, I promise you I started before I saw your post :) http://www.jerf.org/iri/post/2950 http://www.jerf.org/iri/post/2950
thewonderer 10y ago
I'm sorry but this list only provides more evidence that XML is too complicated.
- jerf 10y ago
  First, XML namespaces are an optional add-on, which is definitely not always used. Secondly, when you need namespaces, they're a clean, simple solution to the core problem. When you don't need them, don't use them. Fortunately, unlike some of the DTD stuff which is hard to ignore correctly, it's really easy to not use namespaces. If the complexity comes from the problem, trying to solve it with a too-simple solution is not a virtue. You'll just reinvent the same thing, only worse, and with less library support. For proof... see the endless poorly-supported attempts to do anything even remotely similar for JSON. The good news is that JSON is very simple. The bad news is that when it's too simple, you typically end up with a mess of poorly-designed stuff on top.
- colanderman 10y ago
  OK, propose a simpler mechanism for globally namespacing identifiers. Given that you find three semantic rules to be "too complicated", I suspect you'll have a difficult time doing better.
- SamWhited 10y ago
  I agree, XML is too complicated, but I also don't know of a better tool for the job (and XMPP's only requires a simplified profile of XML). What else provides an ordered collection of anonymous values that can be streamed (eg. you can read just the start tag and have enough information to parse/route the rest of the element), or has 20 years of very fast parsers built for it? I know the whole web has an obsession with JSON lately, and it's great when you need an unordered list of named values, but it's not so great for anything where you need a SAX-style parser, or where you need to be able to rapidly stream data.
  - hyperturtle 10y ago
    SAX-style / streaming parsers do exist for json. http://oboejs.com/ http://oboejs.com/ http://rapidjson.org/md_doc_sax.html http://rapidjson.org/md_doc_sax.html
    - colanderman 10y ago
      JSON has no notion of object "type". So if you have a list of things, whose processing is determined by their type, you may need to parse the entire object before finding the key/value pair that distinguishes its type. Because XML puts the "type" of an object syntactically first, it supports this use case.
    - Mikhail_Edoshin 10y ago
      Pity they don't use it for npm, which cannot create a local search index because of this: it tries to load a large JSON file into memory and fails. I never was able to do this on my VM despite trying to give it more memory (up to 2 GB, at which point I gave up).
- Mikhail_Edoshin 10y ago
  The explanation is complicated. XML has no namespaces, the real namespace of XML is flat and all names are globally unique. The things they call namespaces are long prefixes that can be shortened; also, one prefix can be made default at any point in the tree. By default the prefix is empty. [Edit: rephrase.]

jerf 10y ago

I realized I ought to write it up too, so, I promise you I started before I saw your post :) http://www.jerf.org/iri/post/2950 http://www.jerf.org/iri/post/2950

thewonderer 10y ago

I'm sorry but this list only provides more evidence that XML is too complicated.

jerf 10y ago
First, XML namespaces are an optional add-on, which is definitely not always used. Secondly, when you need namespaces, they're a clean, simple solution to the core problem. When you don't need them, don't use them. Fortunately, unlike some of the DTD stuff which is hard to ignore correctly, it's really easy to not use namespaces. If the complexity comes from the problem, trying to solve it with a too-simple solution is not a virtue. You'll just reinvent the same thing, only worse, and with less library support. For proof... see the endless poorly-supported attempts to do anything even remotely similar for JSON. The good news is that JSON is very simple. The bad news is that when it's too simple, you typically end up with a mess of poorly-designed stuff on top.
colanderman 10y ago
OK, propose a simpler mechanism for globally namespacing identifiers. Given that you find three semantic rules to be "too complicated", I suspect you'll have a difficult time doing better.
SamWhited 10y ago
I agree, XML is too complicated, but I also don't know of a better tool for the job (and XMPP's only requires a simplified profile of XML). What else provides an ordered collection of anonymous values that can be streamed (eg. you can read just the start tag and have enough information to parse/route the rest of the element), or has 20 years of very fast parsers built for it? I know the whole web has an obsession with JSON lately, and it's great when you need an unordered list of named values, but it's not so great for anything where you need a SAX-style parser, or where you need to be able to rapidly stream data.
- hyperturtle 10y ago
  SAX-style / streaming parsers do exist for json. http://oboejs.com/ http://oboejs.com/ http://rapidjson.org/md_doc_sax.html http://rapidjson.org/md_doc_sax.html
  - colanderman 10y ago
    JSON has no notion of object "type". So if you have a list of things, whose processing is determined by their type, you may need to parse the entire object before finding the key/value pair that distinguishes its type. Because XML puts the "type" of an object syntactically first, it supports this use case.
  - Mikhail_Edoshin 10y ago
    Pity they don't use it for npm, which cannot create a local search index because of this: it tries to load a large JSON file into memory and fails. I never was able to do this on my VM despite trying to give it more memory (up to 2 GB, at which point I gave up).
Mikhail_Edoshin 10y ago
The explanation is complicated. XML has no namespaces, the real namespace of XML is flat and all names are globally unique. The things they call namespaces are long prefixes that can be shortened; also, one prefix can be made default at any point in the tree. By default the prefix is empty. [Edit: rephrase.]