4 ms·

I like XMPP but I reckon XML introduced some complexity. For example, many clients (like mcabber) had lots of features broken (e.g. typing notifications) when

by nextos 10y ago

I like XMPP but I reckon XML introduced some complexity. For example, many clients (like mcabber) had lots of features broken (e.g. typing notifications) when interacting with GTalk because they couldn't parse XML namespaces properly.

jerf 10y ago
If you can't parse XML namespaces at least mostly properly, you can't write an XMPP client. Unfortunately, this disqualifies a lot of the less maintained and/or less well-written parsers. It also sometimes disqualifies "bindings" to things like libxml2, when the bindings are written by someone who doesn't understand namespaces and end up wrecking them even though the underlying library supports them fine. XML namespaces are strange to me. I think they're the simplest example of a standard I consider somewhat simple that to a first approximation nobody understands. It really goes to show that there aren't really all that many people who understand XML qua XML. There's a lot of people who understand "there's angle brackets and attributes and sometimes these entities" and not much more, but there's substantially more meat to correctly understanding XML. Unfortunately (and I mean this fully, not sarcastically or with preaching), to use and implement XMPP requires a somewhat more full understanding of XML than most people have. Namespaces are the biggest sticking point, but XMPP is also a bit quirky in that it tries to have an XML stream, which is sensible enough at the protocol level but often translates strangely up to the API level. (The optimum library for XMPP permits you to use a SAX-like parser for the stream opening, then presents a DOM-like view of each individual element, and there aren't very many libraries that allow both sides of that.)
- colanderman 10y ago
  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.
- thom_nic 10y ago
  If you're lucky you can in often get by looking for xmlns attribute on the IQ or message child element and operate on the assumption that you know exactly what namespaces you expect to see a priori. But yes, it's an uphill battle if you don't have a namespace aware XML parser.
  - mikaraento 10y ago
    I think the uphill's not too steep - keeping track of the aliases on your own is quite reasonable. The thing that does _not_ work is not using namespaces to decide on the meaning of tags/attributes when processing XMPP :)
  - deleted 10y ago
    [deleted]
- Mikhail_Edoshin 10y ago
  XML namespaces are pretty simple: they're just really long names with two parts: a long prefix and a small name plus a convenient notation to shorten the long prefixes. Otherwise the pool of names is flat and the names are globally unique. I think it's good.

by nextos 10y ago

jerf 10y ago

If you can't parse XML namespaces at least mostly properly, you can't write an XMPP client. Unfortunately, this disqualifies a lot of the less maintained and/or less well-written parsers. It also sometimes disqualifies "bindings" to things like libxml2, when the bindings are written by someone who doesn't understand namespaces and end up wrecking them even though the underlying library supports them fine. XML namespaces are strange to me. I think they're the simplest example of a standard I consider somewhat simple that to a first approximation nobody understands. It really goes to show that there aren't really all that many people who understand XML qua XML. There's a lot of people who understand "there's angle brackets and attributes and sometimes these entities" and not much more, but there's substantially more meat to correctly understanding XML. Unfortunately (and I mean this fully, not sarcastically or with preaching), to use and implement XMPP requires a somewhat more full understanding of XML than most people have. Namespaces are the biggest sticking point, but XMPP is also a bit quirky in that it tries to have an XML stream, which is sensible enough at the protocol level but often translates strangely up to the API level. (The optimum library for XMPP permits you to use a SAX-like parser for the stream opening, then presents a DOM-like view of each individual element, and there aren't very many libraries that allow both sides of that.)

colanderman 10y ago
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.
thom_nic 10y ago
If you're lucky you can in often get by looking for xmlns attribute on the IQ or message child element and operate on the assumption that you know exactly what namespaces you expect to see a priori. But yes, it's an uphill battle if you don't have a namespace aware XML parser.
- mikaraento 10y ago
  I think the uphill's not too steep - keeping track of the aliases on your own is quite reasonable. The thing that does _not_ work is not using namespaces to decide on the meaning of tags/attributes when processing XMPP :)
- deleted 10y ago
  [deleted]
Mikhail_Edoshin 10y ago
XML namespaces are pretty simple: they're just really long names with two parts: a long prefix and a small name plus a convenient notation to shorten the long prefixes. Otherwise the pool of names is flat and the names are globally unique. I think it's good.