[JDEV] Binary XML useful for Jabber?

Daniel Veillard veillard at redhat.com
Wed May 23 02:23:24 CDT 2001


On Wed, May 23, 2001 at 12:58:20AM +0000, Adam Fritzler wrote:
> On Tue, 22 May 2001, Jens Alfke wrote:
> 
> > One has to assume that the WAP people considered general compression vs. 
> > tokenization, and that they went with the latter because it offered 
> > better compression.
> 
> IMHO, WXML was created as a further ego-booster for the WAP Forum, and to
> complete their uselessly redesigned suite of unoriginal protocols.

  Amen !

> But I'm referring to the WAP specs.  A link was given to w3c, so maybe
> someone is improving it and putting into a less proprietary standards
> track.

  Not that I know of (i.e. not at W3C !). The WAP forum is a W3C member
and as such can provide a contribution for sharing on W3C space. This
doesn't mean that W3C has worked on it or endorsed the proposal.

> In any case, the utility of widely available, long-used _generic_
> compression schemes should not be discounted.  Only design/use custom
> schemes where they provide a fundamental improvement in performance (not
> just because some wannabe standards body creates them and gives them an
> acronym).

  The problem of a non-generic compression schemes is that usually
it won't evolve well with time, if you look at the one from WAP, reusing
it in another context it may provide less gain than a generic compressor.
And considering the fact that XML is used because of its extensivity, 
I'm afraid that any algorithm based on a predefined set of tokens won't
work well.

> On another note, something that pushes jabber away from wireless devices
> is its dependence (at least what I see as a dependence) on a stream
> transport.  Most wireless transports do not provide reliable, ordered,
> stream delivery.  

  This can be seen as one of the drawback of the initial choice to encode
the protocol as 2 XML streams. I still think that this choice was one
of the brilliant design decision which boosted Jabber when it started.
Of course I'm a bit biased :-) . The capacity to extend the language
through namespaces seems to be widely used, and full support of the 
Unicode at the transport level sounds very important too. Maybe in a couple
of year when we have a more mature point of view someone will have to
collect the good of bad points of the initial design decisions.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



More information about the JDev mailing list