Hacker News Reader

Comment by nextos | Hacker News Reader

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.

View on HN

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

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

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

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

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.

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.

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.

SAX-style / streaming parsers do exist for json. http://oboejs.com/ http://rapidjson.org/md_doc_sax.html

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.

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

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

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.

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 :)

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.

Reply on news.ycombinator.com