TAG review of EXI Best Practices
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
TAG review of EXI Best Practices
by Henry S. Thompson
::
Rate this Message:
-----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@... 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----- |
|
|
RE: TAG review of EXI Best Practices
by Taki Kamiya
::
Rate this Message:
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@... [mailto:public-exi-request@...] On Behalf Of Henry S. Thompson Sent: Thursday, October 02, 2008 6:43 AM To: public-exi@... Cc: www-tag@... 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@... 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----- |
|
|
RE: TAG review of EXI Best Practices
by noah_mendelsohn
::
Rate this Message:
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@...> Sent by: www-tag-request@... 10/29/2008 07:50 PM To: "'Henry S. Thompson'" <ht@...>, <www-tag@...> cc: <public-exi@...>, (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@... [mailto:public-exi-request@...] On Behalf Of Henry S. Thompson Sent: Thursday, October 02, 2008 6:43 AM To: public-exi@... Cc: www-tag@... 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@... 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----- |
|
|
RE: TAG review of EXI Best Practices
by Taki Kamiya
::
Rate this Message:
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@... [mailto:public-exi-request@...] On Behalf Of noah_mendelsohn@... Sent: Tuesday, February 17, 2009 5:52 PM To: Taki Kamiya Cc: 'Henry S. Thompson'; public-exi@...; www-tag@...; 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@...> Sent by: www-tag-request@... 10/29/2008 07:50 PM To: "'Henry S. Thompson'" <ht@...>, <www-tag@...> cc: <public-exi@...>, (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@... [mailto:public-exi-request@...] On Behalf Of Henry S. Thompson Sent: Thursday, October 02, 2008 6:43 AM To: public-exi@... Cc: www-tag@... 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@... 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----- |
|
|
RE: TAG review of EXI Best Practices
by noah_mendelsohn
::
Rate this Message:
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@...> 02/28/2009 10:03 PM To: <noah_mendelsohn@...>, <www-tag@...> cc: <public-exi@...>, "'Henry S. Thompson'" <ht@...>, "'David Orchard'" <orchard@...> 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@... [mailto:public-exi-request@...] On Behalf Of noah_mendelsohn@... Sent: Tuesday, February 17, 2009 5:52 PM To: Taki Kamiya Cc: 'Henry S. Thompson'; public-exi@...; www-tag@...; 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@...> Sent by: www-tag-request@... 10/29/2008 07:50 PM To: "'Henry S. Thompson'" <ht@...>, <www-tag@...> cc: <public-exi@...>, (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@... [mailto:public-exi-request@...] On Behalf Of Henry S. Thompson Sent: Thursday, October 02, 2008 6:43 AM To: public-exi@... Cc: www-tag@... 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@... 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----- |
|
|
RE: TAG review of EXI Best Practices
by Taki Kamiya
::
Rate this Message:
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@... [mailto:noah_mendelsohn@...] Sent: Monday, March 09, 2009 7:12 AM To: Taki Kamiya Cc: 'Henry S. Thompson'; 'David Orchard'; public-exi@...; www-tag@... 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@...> 02/28/2009 10:03 PM To: <noah_mendelsohn@...>, <www-tag@...> cc: <public-exi@...>, "'Henry S. Thompson'" <ht@...>, "'David Orchard'" <orchard@...> 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@... [mailto:public-exi-request@...] On Behalf Of noah_mendelsohn@... Sent: Tuesday, February 17, 2009 5:52 PM To: Taki Kamiya Cc: 'Henry S. Thompson'; public-exi@...; www-tag@...; 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@...> Sent by: www-tag-request@... 10/29/2008 07:50 PM To: "'Henry S. Thompson'" <ht@...>, <www-tag@...> cc: <public-exi@...>, (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@... [mailto:public-exi-request@...] On Behalf Of Henry S. Thompson Sent: Thursday, October 02, 2008 6:43 AM To: public-exi@... Cc: www-tag@... 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@... 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----- |
|
|
RE: TAG review of EXI Best Practices
by Stanley A. Klein-2
::
Rate this Message:
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@... [mailto:noah_mendelsohn@...] > Sent: Monday, March 09, 2009 7:12 AM > To: Taki Kamiya > Cc: 'Henry S. Thompson'; 'David Orchard'; public-exi@...; > www-tag@... > 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@...> > 02/28/2009 10:03 PM > > To: <noah_mendelsohn@...>, <www-tag@...> > cc: <public-exi@...>, "'Henry S. Thompson'" > <ht@...>, "'David Orchard'" <orchard@...> > 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@... [mailto:public-exi-request@...] On > Behalf Of noah_mendelsohn@... > Sent: Tuesday, February 17, 2009 5:52 PM > To: Taki Kamiya > Cc: 'Henry S. Thompson'; public-exi@...; www-tag@...; 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@...> > Sent by: www-tag-request@... > 10/29/2008 07:50 PM > > To: "'Henry S. Thompson'" <ht@...>, <www-tag@...> > cc: <public-exi@...>, (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@... [mailto:public-exi-request@...] On > Behalf Of Henry S. Thompson > Sent: Thursday, October 02, 2008 6:43 AM > To: public-exi@... > Cc: www-tag@... > 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@... > 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----- > > > > > > > -- |
|
|
RE: TAG review of EXI Best Practices
by Taki Kamiya
::
Rate this Message:
Dear Noah and TAG members,
The EXI WG is delighted to report that the content-coding tag "exi" has been registered in the IANA registry [1]. This, together with the less preferred, yet valuable alternative identification method offered by the internet media type "application/exi", will greatly help programs identify streams as EXI in diverse variety of protocols. This content-coding value will be mentioned in the CR version of EXI specification which is expected to be ready for publication soon after the TPAC week. [1] http://www.iana.org/assignments/http-parameters Thank you, Taki Kamiya for the EXI Working Group -----Original Message----- From: noah_mendelsohn@... [mailto:noah_mendelsohn@...] Sent: Monday, March 09, 2009 7:12 AM To: Taki Kamiya Cc: 'Henry S. Thompson'; 'David Orchard'; public-exi@...; www-tag@... 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@...> 02/28/2009 10:03 PM To: <noah_mendelsohn@...>, <www-tag@...> cc: <public-exi@...>, "'Henry S. Thompson'" <ht@...>, "'David Orchard'" <orchard@...> 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@... [mailto:public-exi-request@...] On Behalf Of noah_mendelsohn@... Sent: Tuesday, February 17, 2009 5:52 PM To: Taki Kamiya Cc: 'Henry S. Thompson'; public-exi@...; www-tag@...; 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@...> Sent by: www-tag-request@... 10/29/2008 07:50 PM To: "'Henry S. Thompson'" <ht@...>, <www-tag@...> cc: <public-exi@...>, (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@... [mailto:public-exi-request@...] On Behalf Of Henry S. Thompson Sent: Thursday, October 02, 2008 6:43 AM To: public-exi@... Cc: www-tag@... 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@... 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----- |
|
|
RE: TAG review of EXI Best Practices
by noah_mendelsohn
::
Rate this Message:
The TAG considered the attached email during our recent face-to-face
meetings in Santa Clara. I am pleased to formally convey to members of the EXI Working Group that the TAG thanks you for registering the "exi" content-coding, and we appreciate the attention you have given to our concerns in this area. We wish you all success in your work on Efficient XML Interchange. Noah Mendelsohn For the Technical Architecture Group (TAG) P.S. Tracker: I believe this discharges TAG ACTION-328 -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "Taki Kamiya" <tkamiya@...> Sent by: www-tag-request@... 11/02/2009 02:00 AM To: <noah_mendelsohn@...> cc: <public-exi@...>, <www-tag@...> Subject: RE: TAG review of EXI Best Practices Dear Noah and TAG members, The EXI WG is delighted to report that the content-coding tag "exi" has been registered in the IANA registry [1]. This, together with the less preferred, yet valuable alternative identification method offered by the internet media type "application/exi", will greatly help programs identify streams as EXI in diverse variety of protocols. This content-coding value will be mentioned in the CR version of EXI specification which is expected to be ready for publication soon after the TPAC week. [1] http://www.iana.org/assignments/http-parameters Thank you, Taki Kamiya for the EXI Working Group -----Original Message----- From: noah_mendelsohn@... [mailto:noah_mendelsohn@...] Sent: Monday, March 09, 2009 7:12 AM To: Taki Kamiya Cc: 'Henry S. Thompson'; 'David Orchard'; public-exi@...; www-tag@... 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@...> 02/28/2009 10:03 PM To: <noah_mendelsohn@...>, <www-tag@...> cc: <public-exi@...>, "'Henry S. Thompson'" <ht@...>, "'David Orchard'" <orchard@...> 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@... [mailto:public-exi-request@...] On Behalf Of noah_mendelsohn@... Sent: Tuesday, February 17, 2009 5:52 PM To: Taki Kamiya Cc: 'Henry S. Thompson'; public-exi@...; www-tag@...; 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@...> Sent by: www-tag-request@... 10/29/2008 07:50 PM To: "'Henry S. Thompson'" <ht@...>, <www-tag@...> cc: <public-exi@...>, (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@... [mailto:public-exi-request@...] On Behalf Of Henry S. Thompson Sent: Thursday, October 02, 2008 6:43 AM To: public-exi@... Cc: www-tag@... 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@... 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----- |
| Free embeddable forum powered by Nabble | Forum Help |
