[jdev] Limitations of XML Namespaces use

[Ralph Meijer]

On Tue, Jul 04, 2006 at 07:08:14PM +0200, Manuzhai wrote:
> 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.

Hi!

Sure that's interesting. I've been working on the Twisted Jabber support
for a while now. I specifically chose to go on using what dizzyd (Dave
Smith) started in the domish module, mostly because of the issues you
point out below. This choice meant not using ElementTree, at least for
now. But this work might persuade me.

I'm not sure why you've started yet another python XMPP implementation,
though, so I am curious about that. Maybe you could work on improving
Twisted's Jabber support instead? If you want to chat about this,
contact me at <xmpp:ralphm at ik.nu>.

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

This is mostly for compatibility with pre-XMPP implementations of the
Jabber protocols. Some of the elders might expand on this.

Changing this requirement would surely break most of the current
implementations out there. It basically comes down to the good old: be
conservative with what you send, liberal with what you except.

-- 
Groetjes,

ralphm