[Standards] NEW: XEP-0225 (Component Connections)
justin-keyword-jabber.093179 at affinix.com
Fri Aug 10 18:19:59 UTC 2007
On Friday 10 August 2007 12:20 am, Ralph Meijer wrote:
> My namespace handing code has None besides the typical empty and
> non-empty namespace names. None means inheriting from whatever is the
> default namespace of the parent (or closest ancestor that sets this. So,
> I convert the namespace to None on incoming messages and to the stream
> namespace on outgoing messages.
Good approach, and it makes sense given how XMPP works. Unfortunately, it
requires a special data structure as opposed to a standard DOM, which does
not have the notion of an inherited/default namespace (yes, I keep bringing
up DOM... but standard XML tools are good.). It just occurred to me though,
that maybe I could add my own namespaced attribute onto the elements
indicating the default namespace, which would be stripped at the time of
transmission. Yay for DOM hacks. :)
> This keeps namespace changes at the edges. Not having a defined default
> namespace the elements in transit between parts of the server make sense
> to me, as they don't actually belong to any of the currently defined
> stream namespaces.
This I'd argue with. Take my example again about <body>. This element is
defined to be in the jabber:client or jabber:server namespace. What is its
meaning in an undefined or None namespace, according to your implementation?
Presumably it gains either 'jabber:client' or 'jabber:server' meaning when it
becomes time to process it. It must belong to one of those namespaces (or
somehow both) at the time of processing, because otherwise the element would
be meaningless. If you have stanza code that processes <body>, but does not
care about the namespace of the body element, then that to me is a little bit
> That said, all server implementations need to do this namespace juggling
> anyway, so I don't see how it is an extra burden to do this for another
> namespace, too.
What doesn't sit well with me is this idea of the standard elements having to
live under any random namespace. The namespace is what gives them meaning.
If we only ever have exactly two (or potentially with a component namespace,
exactly three) possible namespaces for the elements, maybe that is fine.
What is not fine is having to worry that someday down the line we may invent
yet another namespace that the standard elements must be able to operate
under. Is <body> omnipresent, and existing potentially in all namespaces? :)
More information about the Standards