[Standards] NEW: XEP-0225 (Component Connections)

Justin Karneges 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 
goofy.

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

-Justin



More information about the Standards mailing list