- From: Taki Kamiya <tkamiya@us.fujitsu.com>
- Date: Wed, 29 Oct 2008 16:50:22 -0700
- To: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, <www-tag@w3.org>
- Cc: <public-exi@w3.org>
Dear TAG members, Per the resolution in the joint meeting in TPAC last week, we have updated the working copy of the EXI format specification to add a caveat regarding the use of content-coding in EXI, clarifying that it is applicable only to XML documents and it is neither byte- nor character-preserving. Note that, since EXI Best Practices document was last updated, the EXI specification has described its use of content coding and internet media type in the appendix. We believe that the above mentioned caveat fits best into this appendix section. We appreciate TAG's continued attention, guidance and support for our activity, which are all valuable to us. Thank you, Taki Kamiya for the EXI Working Group -----Original Message----- From: public-exi-request@w3.org [mailto:public-exi-request@w3.org] On Behalf Of Henry S. Thompson Sent: Thursday, October 02, 2008 6:43 AM To: public-exi@w3.org Cc: www-tag@w3.org Subject: TAG review of EXI Best Practices -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the TAG, we welcome the expression of the outcome of the discussions at TPAC last year in this document [1]. Presuming this now 10-month-old draft continues to represent the WG's position on the matter, we endorse the commitment to the 'Content Encoding' route as the least-bad alternative available. We would encourage you, however, to devote a bit more space to explaining the details of what this amounts to, in particular the way in which EXI as specified cannot literally take the place of a Content Encoding: 1) It doesn't map text to text; 2) Even if a version of it were specified that did, it is not universal, that is, it _only_ maps XML to XML. Compare this to for example gzip: gzip maps text to encoded text, and back again, whereas EXI as spec'ed maps infosets to encoded text and back again, so a message which says "Content-Encoding: gzip; Content-Type: application/svg+xml" can be understood as saying "Unzip this byte-stream and you'll get a message body to which normal application/svg+xml processing can be applied", whereas a message which says "Content-Encoding: x-gzip; Content-Type: application/svg+xml" cannot be interpreted as saying "EXI-decode this byte-stream, and you'll get a message to which normal application/svg+xml processing can be applied", because the result of the EXI decoding algorithm is not a message body, it's an Infoset. And of course you can gzip anything, whereas you can only EXI-encode XML. ht, on behalf of the TAG [2] [1] http://www.w3.org/TR/2007/WD-exi-best-practices-20071219/ [2] http://www.w3.org/2001/tag/group/track/actions/180 - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFI5M/skjnJixAXWBoRAvGFAJ4yANHqyS6U4zvngnEuetypoS1kGgCdGetr Ftund8ggscvGfmzgqNQ833U= =etF8 -----END PGP SIGNATURE-----
Received on Thursday, 30 October 2008 00:05:57 UTC