RE: EXI WG review of Mobile Web Application Best Practices PR

Dear Mobile Web Best Practices Working Group members,

The EXI WG has reviewed the clarification made in response to our
comments with regards to the mention of EXI in the specification, and
found it has adequately addressed what we felt was in need of clarification 
about.

We would like to thank you for accomodating our perspective at the very
last minute.

Best regards,

Taki Kamiya for the EXI Working Group


-----Original Message-----
From: Francois Daoust [mailto:fd@w3.org] 
Sent: Thursday, December 02, 2010 12:14 PM
To: Taki Kamiya
Cc: public-bpwg-comments@w3.org
Subject: Re: EXI WG review of Mobile Web Application Best Practices PR

Dear Taki Kamiya,

The Mobile Web Best Practices Working Group has carefully reviewed your comment and agreed to clarify the text in section 3.4.1. The
benefits of EXI you mention were precisely what triggered the inclusion of the reference to EXI in the first place. The fact that
the section made it look as if EXI shared the same restrictions as other compression techniques was clearly an oversight. Thanks for
pointing that out!

The group resolved to move the mention of alternative compression techniques to the end of the section and to note that such
techniques do not share some of the impediments of the usual compression techniques.

The updated text may be seen in the following editor's draft:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20101202/#bp-conserve-compress

I would very much appreciate if you could let us know as soon as possible (by Tuesday 7 December 2010, earlier if at all possible)
whether you approve of that disposition. I apologize for the short notice: the group would very much like to be in a position to
meet the moratorium for publication of the end of the year.

Best regards,

On behalf of the Mobile Web Best Practices Working Group,
Francois Daoust, W3C Staff Contact.





On 11/16/2010 09:35 PM, Taki Kamiya wrote:
> Dear Mobile Web BP WG members,
>
> On behalf of the EXI WG, I would like to send in the following comment
> that reflects our review of the document [1] with primary emphasis on section
> 3.4.1 Use Transfer Compression where the use of EXI is described, from
> the technical viewpoint concerning EXI.
>
> We felt that some of the descriptions given in relation to EXI in section 3.4.1.2
> may as well be moderated when it associates EXI with limitations/restrictions
> that are generally true for other representations and compression techniques,
> but not necessarily outright so for EXI. The cause for EXI in fact was to some
> extent to overcome those impediments that relate to processing efficiency,
> battery usage, and the effectiveness on small messages. The rest of this message
> below describes some characteristics of EXI, which we hope will better inform the
> document in a way to build on what is already described in the section and
> improve it to result in more accurate characterization of EXI as it relates to
> the topic discussed in the section.
>
> When the content being transferred is XML in particular, the HTTP content-
> coding parameter value "exi" [2] enables the use of EXI where it is supported.
> EXI is known to make additional benefit available for a diverse use cases of
> XML document exchanges that range independently in aspects such as document
> sizes (including very small files of less than 1k in size), and resourcefulness
> (such as footprint, battery capacity or CPU excellence) of the devices.
>
> EXI streams are observed to be processed consistently faster than the equivalent
> text XML streams can be processed by XML parsers. This is in addition to the file
> size benefit that EXI provides. EXI's compression feature compresses XML files
> more compact than gzip or DEFLATE can achieve, and the compressed EXI streams
> can be decompressed much faster than decompressing streams that were generated
> by gzip or DEFLATE compressions. Section 3 of EXI Evaluation Note [3] describes
> the advantages of EXI that are exhibited consistently across broad range of document
> types from diverse use cases differing in sizes, styles, etc.
>
> This way, EXI uses both processor cycles and network bandwidth more efficiently,
> the combination of which makes EXI very amenable to the efficient use of battery,
> where reduced bandwidth translates into reduced the power consumption for sending
> or receiving the file while the reduced processor cycles can save the power
> necessary for processing the file, and the two power conservations add up
> simultaneously.
>
> [1] http://www.w3.org/TR/2010/PR-mwabp-20101021/
> [2] http://www.iana.org/assignments/http-parameters/
> [3] http://www.w3.org/TR/2009/WD-exi-evaluation-20090407/#results
>
> Best regards,
>
> Taki Kamiya for the EXI Working Group
>
>
>
>

Received on Wednesday, 8 December 2010 02:56:11 UTC