[standards-jig] Namespaces

Dave Smith dizzyd at jabber.org
Wed Aug 7 13:25:35 UTC 2002


Greetings,

Yes, I do agree with Rob's assessment that prefixes should apply on a 
per document basis (as opposed to a per stream basis).

More responses inline (DIZ)...

On Tuesday, August 6, 2002, at 06:24 , Robert Norris wrote:

>> I've implemented the algorithm to do this twice now, in Scheme and
>> OCaml. In fact, the OCaml XMPP library that I'm going to release Real
>> Soon Now lets you specify namespace associations by URI, while the
>> library handles emitting the correct prefixes. The goals that it has to
>> achieve are straightforward, but the details of actually doing it are
>> intricate and very easy to screw up. Is It Worth It?
>
> That's exactly the way I'm planning to implement the stream lib for 1.5.
> And yes, its a pain in the arse - since the 1.5 DOM (such that it is)
> assumes that each object is a document unto itself, it effectively
> involves tracking the stream namespaces, and then each packet gets
> initialised with the tracked namespaces, changing the prefixes on the
> fly. It will work, but its very ugly, and I wish I didn't have to do it.

DIZ: In my DOM (objective-c), I create a XMLQName object that tracks the 
element name and URI. When I go to write a packet out to the socket, my 
serialization routines take into account the default URI for the stream 
and then dynamically generates prefixes or overrides the default 
namespace as necessary. This work of selecting a prefix and/or 
overriding the default namespace _always_ has to be done; we wouldn't 
avoid this by going to a packet == document architecture. This concept 
simply becomes easier and consistent when we say that the other side 
will be able to deal with arbitrary prefixes.
>
>> I have to say it's my opinion that we should leave Jabber the way it is
>> and just dump the whole "streaming document" paradigm in JNG, so that
>> each packet is a self-contained document. Like using XML structure for
>> framing, the "streaming document" looks nice on paper, but I think it's
>> just not worth it because it's too hard to do right. Anyway, I know 
>> this
>> is an unpopular position, so I won't push it further (for now).
>
> I agree completely. The time will come in the not-too-distant future
> where we will need to seperate the transport from the application.
>
DIZ: I'm not against separating transport for application. As for the 
packet == document concept, I think we should probably start that 
discussion by looking at some of the archives of JDEV -- long ago there 
was a big discussion about that concept...maybe that would give us all 
some insight as to why and how the decisions were made. :)

Diz




More information about the Standards mailing list