[jdev] Limitations of XML Namespaces use

[Manuzhai]

Hello all,

I've been working on a new XMPP library implemented using ElementTree, a
very nice XML library which uses the expat parser underneath, and which
has found such widespread use that it will be in the Python 2.5 standard
library. It is coming along nicely, and I will be releasing it as open
source pretty soon. Let me know if anyone is interested.

Now, today I found a message by Ralph Meijer on this list pointing to
section 11.2.2 in RFC 3920, and I was very much surprised by this. I am
talking specifically about this restriction: "An implementation MUST NOT
generate namespace prefixes for elements in the default namespace if the
default namespace is 'jabber:client' or 'jabber:server'. An
implementation SHOULD NOT generate namespace prefixes for elements
qualified by content (as opposed to stream) namespaces other than
'jabber:client' and 'jabber:server'." and the one in 11.2.3.

The XML restrictions in 11.1 make a lot of sense given the structure of
XMPP streams, but it seems very weird to significantly cripple the use
of XML namespaces in XMPP streams with these restrictions. With the XML
namespaces spec (in widespread use, I'd say), these are equivalent:

<ns0:message xmlns:ns0="jabber:client" />
<message xmlns="jabber:client" />

Why was the choice made to impose this restriction on XMPP's use of XML?
Given the importance of XML namespaces throughout the XMPP protocol, it
doesn't make a whole lot of sense to me. I developed my client against
Wildfire Server, and it does the right thing, but I already ran into
some problems with ejabberd concerning the starttls tag (but then
starttls is not in the jabber:client namespace, so the restrictions
shouldn't apply to it, right?).

Anyway, I wonder why it was done this way and I am hoping that these
restrictions could be relaxed in a new version of the RFC (which would
not be a problem for any software using a compliant XML parser).

Regards,

Manuzhai