RE: TAG review of EXI Best Practices

Hi Noah,

It is my understanding that the disucssion between TAG and EXI has revolved
around mainly two issues. One is improving the affinity of EXI to XML and more
broadly to the Web, which involved not only the discussion of the need for a more
robust identifier in the stream header to distinguish EXI from other resources,
but also the better (least worse) way for EXI to integrate into existing XML systems
on the Web. The identifier issue has already been addressed in the format spec,
and the main discussion we had in TPAC last year was mostly about the latter;
in particular, usage of content-coding in the context of HTTP.

Since then, we updated the internal draft of the spec to reflect the TPAC
joint discussion (as I wrote in the email you attached), and are now in the
process of registering cotent-coding tag "exi" by proposing it to ietf-types [1].
There is still some uncertainty in this regard, given that there have been
shown a number of concerns from within that community. We plan to engage more
on this issue for achieving desired resolution, however, we understand that
there is a possibility that we may not get what we requested.

The other issue we jointly discussed before is about the measurements of EXI.
The action was for us to provide articulate, concise demonstration of
clear benefit of EXI that's much more amenable to readers. We have taken the
first step towards that goal, and produced a draft of such a document "Efficient XML
Interchange Evaluation" [2] last year, which as you indicated provided
observation of EXI benefits on the aspect of compactness. We intend to
publish an updated version of evaluation note as soon as it becomes ready,
of which the the main change will be the addition of processing efficiency data and
analysis. Currently we are working on getting reliable numbers on systems and
discussing  how to improve the way we exhibit and describe the data for clarity.
However,  the exact timing of the publication is not clear yet, though we expect
it to happen within the next couple of months.

While I do not know all the context of the TAG's action 176, I do not think
there's much TAG can work on at this moment, until we publish the next draft
of EXI evaluation note.

We appreciate TAG's coninued attention to EXI activity, which keeps us
on alert and reminded of broad implicatioins of EXI that we sometimes
lose sight of while too much focusing on itty-bitty details of the format.

Thank you,

Taki Kamiya for the EXI Working Group


[1] http://www.alvestrand.no/pipermail/ietf-types/2008-October/002103.html
[2] http://www.w3.org/TR/exi-evaluation/


-----Original Message-----
From: public-exi-request@w3.org [mailto:public-exi-request@w3.org] On Behalf Of noah_mendelsohn@us.ibm.com
Sent: Tuesday, February 17, 2009 5:52 PM
To: Taki Kamiya
Cc: 'Henry S. Thompson'; public-exi@w3.org; www-tag@w3.org; David Orchard
Subject: 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 Sunday, 1 March 2009 03:42:36 UTC