W3C home > Mailing lists > Public > www-tag@w3.org > October 2008

RE: TAG review of EXI Best Practices

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>
Message-ID: <AD0D36725A974E59954492AAF029AF31@catarojp>

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

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

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]
Version: GnuPG v1.2.6 (GNU/Linux)

Received on Thursday, 30 October 2008 00:05:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:25 UTC