4 ms·

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

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