About Ruby EXI
This is an experiment in coding an Efficient XML Interchange (EXI) processor with Ruby.
Design notes
Some rambling thoughts on where to go with this.
The aim is not to reinvent the XML-parsing wheel, but rather to layer on top of existing XML parsers. Ruby has several flavors of them, and everyone has a favorite (I think). There should be a driver interface generic and flexible enough to handle all of them.
Right now, Nokogiri is my favorite library, but that may change soon. Its SAX parser doesn't do absolutely everything I'd like it to do. Ox looks promising, if for no other reason than it sells itself as a superior alternative to Nokogiri. :-)
In-memory XML handling is more flexible and feels more natural to work with OO style. SAX, of course, does not consume (as much) memory and is potentially faster. The driver interface should be able to handle either.
EXI revolves around events much like SAX does, but there is not always a one-to-one mapping between EXI and SAX events. The driver will need to be able to generate extra EXI events when necessary. For example, Nokogiri's SAX parser may send a start-element event that also contains the element's attributes and namespace info; in EXI, this would not be just one event, it would be one SE event followed by one or more AT and NS events.
What would be really nice is to map EXI events to foreign objects/events in such a way that the mapping is implicitly two-way. Only the code at the most abstract level would be handling the specifics of going in one direction or another. So we could just say "SAX start-element event <=> EXI SE event (AT event)* (NS event)*" for a mapping and the code would take care of it.
To the extent possible under law,
Lawrence Leonard Gilbert
has waived all copyright and related or neighboring rights to
Ruby EXI.
This work is published from:
United States.