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
