[XML-SIG] Is anyone implementing EXI in Python?

[Stanley A. Klein]

On Wed, 2009-07-15 at 22:26 +0200, Stefan Behnel wrote:
> Hi,
>
> Stanley A. Klein wrote:
> > On Wed, July 15, 2009 1:37 pm, Henry S. Thompson wrote:
> >> Stanley A. Klein writes:
> >>
> >>> Efficient XML Interchange (EXI) is moving toward adoption by W3C.
It
> >>> provides a format for efficiently representing XML documents with
schema-informed and schema-less modes.
> >>>
> >>> There is an open-source Java implementation available.
> >>>
> >>> Is anyone working to implement EXI in Python?
> >>
> >> Don't get me wrong, I think EXI is useful, in the right places, but,
could I ask, why would you want to implement it in Python?  I'd be
very surprised if any Python XML application is spending anything
like
> >> enough time in the raw parsing activity (as opposed to the
> >> structure-building activity) to make the marginal gain you might get
from EXI worth it. . .
> >>
> >> EXI is, IMO, for closely coupled systems in particular messaging
environments where every bit counts, and I guess I'm having
difficulty
> >> imagining Python in such a context. . .
> >
> > EXI is for data interchange.  That can mean messaging or document/data
storage.  SOAP messages are very verbose, and SOAP messaging can
benefit
> > from EXI, especially if the communications channels have bandwidth or
transit time considerations.
> >
> > SOAP is increasingly being considered in a
> > variety of control system applications for which Python makes sense as
an
> > implementation language.  Similarly, scientific applications involving
large amounts of XML-formatted data could benefit from EXI in storing
the
> > data or interchanging it for purposes such as grid processing.
> >
> > The original application that contributed the technology for EXI was
sending web pages to cell phones.
> >
> > In general, any applications implemented in Python that involves
messaging
> > or data storage with either bandwidth or storage volume concerns could
benefit from EXI.  And as best I know there are a growing number of
such
> > applications implemented in Python.
>
> Any XML transmission or storage can benefit from *compression*, often
shrinking the data volume by factors up to 100. I doubt that the savings
of EXI are sufficiently large compared to a well compressed XML stream
that they compensate for the drawbacks of yet another new non-readable
format.
>
> A well chosen compression method is a lot better suited to such
> applications and is already supported by most available XML parsers (or
rather outside of the parsers themselves, which is a huge advantage).
>
>
> > Also, why would Java make sense and Python not?
>
> Because pretty much all XML technologies come from the Java environment?
That doesn't mean that Java is a suitable language for working with
them.
> It only means that it supports them because Java is used for developing
them (often as a reference implementation).
>
> Stefan


It depends on the nature of the XML application.  One feature of EXI is to
support representation of numeric data as bits rather than characters. 
That is very useful in appropriate applications.  There is a measurements
document that shows the compression that was achieved on a wide variety of
test cases.  Straight use of a common compression algorithm does not
necessarily achieve the best results.  Besides, EXI incorporates elements
of common compression algorithm(s) as both a fallback for its schema-less
mode and an additional capability in its schema-informed mode.

EXI is intended for use outboard of the parser, and that would apply
equally well to a Python version.  For example, EXI gets rid of the need
to constantly resend over-the-wire all the namespace definitions with each
message.  The relevant strings would just go into the string table and get
restored from there when the message is converted back.

However, for something like SOAP in certain applications, it may be
eventually desirable to integrate the EXI implementation within the
communications system.  The message sender could reasonably create a
schema-informed EXI version without actually starting from and converting
an XML object.  The recipient would have to convert the EXI back to XML,
parse it, and use the data.

Regarding the format readability, it converts to XML and is readable
there.  Numeric data is most efficiently sent as bits, so that data is
necessarily unreadable until converted.  The value of EXI necessarily
depends on the application.


Stan Klein

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/xml-sig/attachments/20090716/adbbf6df/attachment.htm>