Re: [xml] EXI

[Ed Day <eday obj-sys com>]

As a member of the EXI WG and a user of libxml2, I may be able to 
provide some useful opinions on some of these items.  My responses are 
inline below.

Regards,

Ed


Bjorn Reese wrote:
> Daniel Veillard wrote:
>
>   
> > I also have a huge issue with the 'pluggable codec' part:
> >     
> [...]
>   
> > I really hope the W3C membership, or ultimately Tim Berners-Lee will block
> > something like pluggable codecs, this simply doesn't have its place on
> > something like a W3C specification (c.f. the motto about the full potential
> > of the Web).
> >     
>
> I tend to a agree with you. I was slightly surprised to see pluggable
> codecs in EXI, as I regard this as a higher-level encoding that should
> be defined by a higher-level protocol, not by EXI.
>   
Several WG members have expressed concerns over this as well (me being 
among them).  I'm not sure how it will turn out.

>   
> > Now that I have expresed  my concerns about the content of the spec we can
> > look spearately about any libxml2 implementation. I have a few more concerns
> > there:
> >  - those are first working draft specifications, I know how long it takes
> >    to finish such spec when there is no controversy about them, for something
> >    like EXI it may take a couple of years before you get a finished version
> >    (if any), and being an early implementor usually brings you just more pain
> >    e.g XPointer where I implemented the full early spec and only a tiny, 
> >    near useless fraction ended up as a REC.
> >     
>
> I agree with this concern. I have similar experiences with the bleeding
> edge from other domains. On the other hand, being an early adopter gives
> us the possibility of influencing the final result. That is the dilemma
> of being an early adopter.
>   
I have no experience in going through last call, so I don't know how 
radically it will be altered.  I will say that the spec is based on a 
proven technology that is in use in several domains at this time; it is 
not something new that has been invented.

>   
> >  - who would use it ? I mean EXI target very specialized domain spaces
> >    like embedded or specific processing, would those people actually use
> >    a libxml2 version where the point is more genericity of usage and
> >    the size and portability designs of the library probably don't match
> >    the specific requirements of those use cases.
> >     
>
> Embedded applications are a fast growing domain.
>
> Also, EXI scales better than XML regardless of the domain.
>   
If you check out the XBC Use Cases document, a number of expected use 
cases are provided.  In addition to mobile, scientific applications that 
need to process large amounts of data very quickly seem to be another 
potential major user.

>   
> >   Assuming the types are really compatible, yes. I just find crazy 
> > to mix layers like this, but again it's a spec concern, less of an implemtnation
> > one ... except for the fact that if you compile Schemas support in the 
> > library size grows a lot.
> >     
>
> Data types are a logical (and even an inevitable) extension if we want
> a binary encoding of structured data. All formats that I am familiar
> with (e.g. RPC or Corba) support different data types.
>
> The problem in the context of XML is that even the primitive data types
> are defined by XML Schema, which is an overly complicated way of
> defining them.
>
>   
> >   yes. Also note that the validations parts of libxml2 and espcially
> > the regexp/automata support is really built for validation far less for
> > introspection, this may present a challenge (but I'm not sure).
> >     
>
> An XML Schema introspection interface could be a valuable extension to
> libxml in its own right. I have certainly had the need for such a thing.
>   
I think the libxml2 schema support in general would need to be updated 
in a major way if you were to do EXI.  I think the answer might be to do 
the sort of thing as was done with XML security which is to have another 
library (i.e project) that uses libxml2 to provide EXI support 
(something like a libexi).  Building EXI support into libxml2 would 
cause the library size to grow considerably, and, as Daniel said, EXI is 
not XML (and nobody is disputing that).

>   
> >   That I have a big grief against as previously explained, it's probably
> > too early to look at this from a technical viewpoint as I think it will
> > take time to settle down from a standard/political one ;-)
> >     
>
> Agreed.
>
>   
> >   I hope I don't sound too negative, but I have a hard time to be convinced
> > by EXI myself. On the other hand libxml2 development should be user demand
> > driven, and to some extend my participation in the XML Core group itself
> > is as representative of the libxml2 community. So if others could voice in
> > it would be a good idea. Also we have IMHO plenty of time, it's not like
> > EXI is about to become a REC, this is just a first draft with all the 
> > associated uncertainties about its content or schedule.
> >     
>
> You actually sound more positive than I had feared.
>
> I agree that a decision on EXI should involve user demands. I would not
> embark on its implementation unless there is a need.
>
>   
> >   Thanks Bjorn for raising the issue, even if this may not be a very
> > simple one :-)
> >     
>
> You are most welcome ;-)
>
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml
>
>
>   


--
Ed Day
Objective Systems, Inc.
http://www.obj-sys.com