Re: Is anyone implementing EXI in Python?
"Stanley A. Klein" <[email protected]> Thu, 16 Jul 2009 14:34:45 -0400 (EDT)
| Newsgroups | gmane.comp.python.xml |
|---|---|
| Message-ID | <[email protected]> |
------=_20090716143445_80830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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/dat= a 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 a= s an > > implementation language. Similarly, scientific applications involvin= g 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 coul= d 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 t= o support representation of numeric data as bits rather than characters.=20 That is very useful in appropriate applications. There is a measurements document that shows the compression that was achieved on a wide variety o= f 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 eac= h message. The relevant strings would just go into the string table and ge= t 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 ------=_20090716143445_80830 Content-Type: text/html; name="untitled-2" Content-Disposition: attachment; filename="untitled-2" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8= "> <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.16.3"> </HEAD> <BODY> <BR> On Wed, 2009-07-15 at 22:26 +0200, Stefan Behnel wrote: <BLOCKQUOTE TYPE=3DCITE> <PRE> <!--+GtkHTML:<DATA class=3D"ClueFlow" key=3D"orig" value=3D"1">--><FONT C= OLOR=3D"#000000">Hi,</FONT> <FONT COLOR=3D"#000000">Stanley A. Klein wrote:</FONT> <FONT COLOR=3D"#000000">> On Wed, July 15, 2009 1:37 pm, Henry S. Thom= pson wrote:</FONT> <FONT COLOR=3D"#000000">>> Stanley A. Klein writes:</FONT> <FONT COLOR=3D"#000000">>></FONT> <FONT COLOR=3D"#000000">>>> Efficient XML Interchange (EXI) is m= oving toward adoption by W3C. It</FONT> <FONT COLOR=3D"#000000">>>> provides a format for efficiently re= presenting XML documents with</FONT> <FONT COLOR=3D"#000000">>>> schema-informed and schema-less mode= s.</FONT> <FONT COLOR=3D"#000000">>>></FONT> <FONT COLOR=3D"#000000">>>> There is an open-source Java impleme= ntation available.</FONT> <FONT COLOR=3D"#000000">>>></FONT> <FONT COLOR=3D"#000000">>>> Is anyone working to implement EXI i= n Python?</FONT> <FONT COLOR=3D"#000000">>></FONT> <FONT COLOR=3D"#000000">>> Don't get me wrong, I think EXI is usefu= l, in the right places, but,</FONT> <FONT COLOR=3D"#000000">>> could I ask, why would you want to imple= ment it in Python? I'd be</FONT> <FONT COLOR=3D"#000000">>> very surprised if any Python XML applica= tion is spending anything like</FONT> <FONT COLOR=3D"#000000">>> enough time in the raw parsing activity = (as opposed to the</FONT> <FONT COLOR=3D"#000000">>> structure-building activity) to make the= marginal gain you might get</FONT> <FONT COLOR=3D"#000000">>> from EXI worth it. . .</FONT> <FONT COLOR=3D"#000000">>></FONT> <FONT COLOR=3D"#000000">>> EXI is, IMO, for closely coupled systems= in particular messaging</FONT> <FONT COLOR=3D"#000000">>> environments where every bit counts, and= I guess I'm having difficulty</FONT> <FONT COLOR=3D"#000000">>> imagining Python in such a context. . .<= /FONT> <FONT COLOR=3D"#000000">></FONT> <FONT COLOR=3D"#000000">> EXI is for data interchange. That can mean = messaging or document/data</FONT> <FONT COLOR=3D"#000000">> storage. SOAP messages are very verbose, an= d SOAP messaging can benefit</FONT> <FONT COLOR=3D"#000000">> from EXI, especially if the communications c= hannels have bandwidth or</FONT> <FONT COLOR=3D"#000000">> transit time considerations.</FONT> <FONT COLOR=3D"#000000">></FONT> <FONT COLOR=3D"#000000">> SOAP is increasingly being considered in a</= FONT> <FONT COLOR=3D"#000000">> variety of control system applications for w= hich Python makes sense as an</FONT> <FONT COLOR=3D"#000000">> implementation language. Similarly, scienti= fic applications involving</FONT> <FONT COLOR=3D"#000000">> large amounts of XML-formatted data could be= nefit from EXI in storing the</FONT> <FONT COLOR=3D"#000000">> data or interchanging it for purposes such a= s grid processing.</FONT> <FONT COLOR=3D"#000000">></FONT> <FONT COLOR=3D"#000000">> The original application that contributed th= e technology for EXI was</FONT> <FONT COLOR=3D"#000000">> sending web pages to cell phones.</FONT> <FONT COLOR=3D"#000000">></FONT> <FONT COLOR=3D"#000000">> In general, any applications implemented in = Python that involves</FONT> <FONT COLOR=3D"#000000">> messaging</FONT> <FONT COLOR=3D"#000000">> or data storage with either bandwidth or sto= rage volume concerns could</FONT> <FONT COLOR=3D"#000000">> benefit from EXI. And as best I know there = are a growing number of such</FONT> <FONT COLOR=3D"#000000">> applications implemented in Python.</FONT> <FONT COLOR=3D"#000000">Any XML transmission or storage can benefit from = *compression*, often</FONT> <FONT COLOR=3D"#000000">shrinking the data volume by factors up to 100. I= doubt that the savings of</FONT> <FONT COLOR=3D"#000000">EXI are sufficiently large compared to a well com= pressed XML stream that</FONT> <FONT COLOR=3D"#000000">they compensate for the drawbacks of yet another = new non-readable format.</FONT> <FONT COLOR=3D"#000000">A well chosen compression method is a lot better = suited to such</FONT> <FONT COLOR=3D"#000000">applications and is already supported by most ava= ilable XML parsers (or</FONT> <FONT COLOR=3D"#000000">rather outside of the parsers themselves, which i= s a huge advantage).</FONT> <FONT COLOR=3D"#000000">> Also, why would Java make sense and Python n= ot?</FONT> <FONT COLOR=3D"#000000">Because pretty much all XML technologies come fro= m the Java environment?</FONT> <FONT COLOR=3D"#000000">That doesn't mean that Java is a suitable languag= e for working with them.</FONT> <FONT COLOR=3D"#000000">It only means that it supports them because Java = is used for developing</FONT> <FONT COLOR=3D"#000000">them (often as a reference implementation).</FONT= > <FONT COLOR=3D"#000000">Stefan</FONT> </PRE> </BLOCKQUOTE> </BODY> </HTML> ------=_20090716143445_80830 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XML-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/xml-sig ------=_20090716143445_80830--