RE: TAG review of EXI Best Practices

I don't understand some of the document's conclusions regarding
compactness in comparison to ASN.1 PER.  Do the conclusions apply to cases
where the data is naturally binary, such as 32 bit integer or real?  The
use case I have in mind is sensor data.  I didn't notice a feature in EXI
that allowed 32 bit binary to be sent without converting it to character,
as would occur in transmitting a value as XML.

I think that can be done by using a user-defined datatype representation,
but that is the only way I can identify.  If that is the case, there
probably needs to be a standard "user-defined" datatype representation
that escapes to four octets for representing 32 bit binary or 8 octets for
64 bit binary, with definitions in each case for integer and real.

Alternatively, if the compactness of naturally binary data using EXI is as
good or better than ASN.1 PER +20%, how does that happen?


Stan Klein



On Tue, April 21, 2009 4:33 pm, Taki Kamiya wrote:
> Dear Noah and TAG members,
>
> We would like to call the TAG's attention to the recent publication of the
> second working draft of the EXI Evaluation working note [1].
>
> The primary change since the first draft is the addition of processing
> efficiency results which indicate the expected performance of
> EXI relative to XML and XML+GZIP for both encoding and decoding.
>
> We hope that the data addresses concerns that we have discussed previously
> in joint sessions between the TAG and the EXI WG. We will be convening
> a face-to-face meeting during May 5-7th.  We would appreciate any feedback
> the TAG can provide by that time.
>
> [1] http://www.w3.org/TR/2009/WD-exi-evaluation-20090407/
>
> Best regards,
>
> Mike Cokus and Taki Kamiya
> (EXI Working Group co-chairs)
>
>
> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Monday, March 09, 2009 7:12 AM
> To: Taki Kamiya
> Cc: 'Henry S. Thompson'; 'David Orchard'; public-exi@w3.org;
> www-tag@w3.org
> Subject: RE: TAG review of EXI Best Practices
>
> Thank you very much.  Your response exactly matches my understanding of
> the status of the EXI work and of our efforts to coordinate.
>
> Taki Kamiya wrote:
>
>> 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.
>
> Subject to agreement from the rest of the TAG, I will:
>
> * close our ACTION-176
> * establish myself as our TAG shepherd for TAG ISSUE-30 (binaryXML-30
> Standardize a "binary XML" format?)
> * update the description of that issue to point to your note below, and to
> indicate that we will await further word from you on a) developments
> relating to the use of Content-encoding or similar mechanisms, and b) the
> possibile availability of a more detailed peformance analysis from you.
>
> We would very much appreciate it if you would keep us informed of
> significant developments in these areas.  Thank you very much.
>
> Noah Mendelsohn
> TAG co-chair
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> "Taki Kamiya" <tkamiya@us.fujitsu.com>
> 02/28/2009 10:03 PM
>
>         To:     <noah_mendelsohn@us.ibm.com>, <www-tag@w3.org>
>         cc:     <public-exi@w3.org>, "'Henry S. Thompson'"
> <ht@inf.ed.ac.uk>, "'David Orchard'" <orchard@pacificspirit.com>
>         Subject:        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 Wednesday, 22 April 2009 21:36:33 UTC