RE: TAG review of EXI Best Practices

You sent this note many months ago, but I am (finally) moved to respond 
now.   Please accept my apologies for the delay.   In particular, I would 
like to inquire as to whether the EXI working group is currently waiting 
on or expecting any particular response from the TAG in relation to the 
attached email?  The reason I ask  is that the TAG has for some months 
been tracking an action assigned to me and to Dave Orchard, though since 
he's graduated from the TAG it now falls just to me.  Anyway, our 
ACTION-176 [1] asks that Dave and I "send comments on exi w.r.t. 
evaluation and efficiency" to you. 

When I was reminded of this issue a few months ago, my intuition was that 
it had in fact been assigned before TPAC, and that whatever interaction 
was at the time required between the TAG and the EXI group indeed happened 
at TPAC, if not before, and that the action should probably have been 
closed after TPAC.  Just when I was about to revisit this, I was appointed 
TAG chair, which not surprisingly proved a bit of a distraction for 
awhile.  Anyway, with great embarassment for the delay, I am now 
revisiting the history of this action, and I find that it indeed was 
originally assigned ahead of TPAC [2].  This somewhat supports, but does 
not completely confirm, my intuition that in fact that action should have 
been marked CLOSED at that time.  FWIW, I see in the minutes of our 
session at TPAC [3] my mentioning some existing TAG actions, presumably 
including 176.  Though I doubt there's anything tremendously sensitive, I 
see that your WG minutes are member-only, so I won't quote them here. They 
do include some mention by me of the fact that further details on speed 
(as opposed to compression) would be helpful, and my impression is that 
there was agreement that you would work on those.

Anyway, I'd like to propose a reset, on the following basis.

1) My recollection is that, at TPAC, you made the case that suitably well 
documented compression results had been provided for EXI, and we in the 
TAG agreed, at least informally.  So, unless something changes, the TAG 
does not expect to again raise questions about the compactness achievable 
with EXI.
2) As noted above, my recollection is that you were intending to write a 
more careful analysis of speed results, and that we on the TAG expressed 
at least an informal interest in seeing them.  Please let us know whether 
such a document has indeed been produced, if not whether you still intend 
to produce it, whether my recollection of the history is flawed, etc..
3) If you are waiting on any other feedback from the TAG right now, please 
clarify what it is.  Once you confirm that you are not, I will close TAG 
action 176.

This is just a proposal from me, not a formal proposal from the TAG, but 
if you agree that the above is appropriate I will confirm with other TAG 
members that it is acceptable to them. If not, please suggest what might 
be a better approach.

Of course, if you wish to consult us on some matter in the future, we will 
be glad to try and help, and we reserve the right to raise new questions 
should we become aware of them in the future.  That said, when last we 
discussed this, the TAG felt that you and the community were in general 
aware of our concerns regarding the analysis of EXI speed, and at least 
informally, I can say that we have no expectation at this point of doing 
anything that would impede your progress toward Recommendation.  Thank you 
very much

Noah Mendelsohn

[1] http://www.w3.org/2001/tag/group/track/actions/176
[2] http://www.w3.org/2001/tag/group/track/actions/176?changelog
[3] http://www.w3.org/2008/10/20-exi-minutes.html#item02

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Taki Kamiya" <tkamiya@us.fujitsu.com>
Sent by: www-tag-request@w3.org
10/29/2008 07:50 PM
 
        To:     "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, <www-tag@w3.org>
        cc:     <public-exi@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: TAG review of EXI Best Practices



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 Wednesday, 18 February 2009 01:51:26 UTC