On Tue, 2007-12-25 at 23:35 -0500, Daniel Veillard wrote: > 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 would agree and disagree at same time. Yes, it is way of trials and error, but if nobody will try to follow new standard It will never becomes perfect enough. > - 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. I can't say for wide range of ppl, but I definitely going to use EXI. I've use libxml for several years (in fact since libxml2 appearance). And was forced to develop simple internal implementation of something like EXI to address similar problems that was addressed by EXI. > An implementation just for the sake of being able to claim existence of > a widely distributed early implementor doesn't sound to me a good reason > to put EXI in libxml2. It sounds like a bad news for me. > So now that I'm done expressing my doubts about it, let's see the technical > points which an implementation in libxml2 would raise :-) > > > issues that I came across are: > > > > First, the EXI implementation should be an independent parser (and > > generator) front-end. It should emmanate SAX events, so that we can > > seamlessly use SAX, DOM, and xmlReader for EXI documents. Hopefully > > this will also allow us to use all the other XML technologies (XPath, > > XML Schema, XSLT, etc.) that libxml supports. I do not know the details > > of libxml well enough to evaluate if this is indeed the case. > > Yes like for the HTML parser the right thing to do is to plug at the > SAX level to allow a flow of event, possibly connecting to tree and > reader APIs. Note also that a read-only interface is really not sufficient > you want to be able to save, if you can't round-trip it's really of > limited use or indication of a serious problem. > > > Second, EXI has some built-in datatypes that are like the XML Schema > > datatypes. Obviously, some code should be reused here. > > 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. > > > Third, EXI supports a schema-informed grammar, which means that it can > > use information found in XML Schemas, RELAX NG schemas, or DTDs to > > create a more compact EXI document. Although the schema-informed grammar > > is independent on the various schemas (XML Schema, RELAX NG, DTD), it > > eventually has to be populated by those schemas, so it will create some > > kind of dependency to these parts of libxml. > > 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). > > > Fourth, EXI allows (but does not mandate) the support of user-defined > > CODECS for encoding and decoding contents. As this is optional, I have > > not looked further into that, but obviously it should be considered if > > and how this should be supported by libxml. > > 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. > > Thanks Bjorn for raising the issue, even if this may not be a very > simple one :-) > > Daniel -- Vladimir B. Grebenschikov [EMAIL PROTECTED] _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
