Re: [xml] EXI

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.

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
 - 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.

 - 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.

  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.

  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 ;-)


  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 ;-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]