AW: Response to LC-2715

Hi Rumen, all,

I would like to respond to your comments (LC-2706, LC-2714, and LC-2715) in a single email since our response is heading towards the same direction.

The EXI working group really appreciates your view and plans to incorporate your comments as follows.

As alluded in my previous emails, the next updated version of the profile will introduce a "Guidelines" section. In regard to restricted devices, this new section is going to give advice for sensible default options for both, the EXI profile and the EXI1.0 baseline spec. However, we do not plan to prohibit users experimenting with the various options to best fit their needs.

We hope this solves your issue,

-- Daniel


________________________________
Von: Rumen Kyusakov [rumen.kyusakov@ltu.se]
Gesendet: Montag, 19. November 2012 11:02
An: Peintner, Daniel (ext)
Cc: public-exi-comments@w3.org
Betreff: Re: Response to LC-2715

Hi Daniel,

Thanks for the explanation! It is indeed more clear to me now why
localValuePartitions parameter was included. I agree that there are
scenarios that using it will be beneficial for both processing and
memory usage.
My concern is again that choosing proper values for the parameters:
valueMaxLength, valuePartitionCapacity, localValuePartitions, for
particular application is not trivial.
Using "unbounded" as default value in the EXI spec is quite reasonable.
For the EXI Profile that is targeted at microcontrollers I think more
restrictive values are required - at least as defaults.

Best Regards,
Rumen Kyusakov


On Thu, 2012-11-15 at 09:10 +0100, Peintner, Daniel (ext) wrote:
> Hi Rumen,
>
> Once again we would like to thank you for your comments.
>
> Please find our response inline.
>
> > When reading up on the EXI specification section "7.3.3 Partitions
> > Optimized for Frequent use of String Literals" last two paragraphs
> > regarding the processing of value content items, I have one more issue
> > to rise connected to the EXI Profile:
> > In section "3. Local Value Capping" the parameter localValuePartitions
> > is used to turn on or off the use of local value partitions. Note
> > however that this same effect can be achieved by the use of the EXI
> > parameter valuePartitionCapacity - it is not only used for the global
> > value indexing.
> > Setting valuePartitionCapacity to 0 effectively turns off both local and
> > global value string tables.
> > So the localValuePartitions parameter of the EXI profile has effect only
> > when valuePartitionCapacity is greater than 0.
>
> Your understanding is correct.
>
> > However, the use of global value tables (valuePartitionCapacity > 0)
> > while turning off only the local value tables (localValuePartitions = 0)
> > is something that is highly unlikely to be useful in any scenario.
> >
> > So why having yet another parameter for something that is already
> > available as option in the EXI specification?
>
> Most binary XML formats we are aware of provide one global string table. EXI is more sophisticated in that regard providing global and local string tables according to the qualified name.
>
> While this is beneficial in regard to compression it also induces more processing. That said, turning off local value partitions while at the same time allowing global string table entries (localValuePartitions = 0 and valuePartitionCapacity > 0) provides benefit. As alluded doing so reduces complexity, especially on decoder side, by also simplifying the round-robin replacement strategy. Moreover, a given value for the valuePartitionCapacity option guarantees an upper bound for global value hits (in terms of number of entries and bits) while a local-value hit counter may indefinitely grow.
>
> We hope that these further explanations make you agree with us that providing the localValuePartitions option in the profile is useful.
>
> Thanks,
>
> -- Daniel
>

Received on Thursday, 6 December 2012 12:57:02 UTC