W3C home > Mailing lists > Public > public-exi-comments@w3.org > November 2012

Re: [LC-2711] The Profile parameters

From: Rumen Kyusakov <rumen.kyusakov@ltu.se>
Date: Mon, 12 Nov 2012 11:28:33 +0100
To: public-exi-comments@w3.org
Message-ID: <1352716113.1923.30.camel@rumkyu-desktop>
Hi Taki,

Thank you for the response - lessening compliance requirements regarding
the parameters communication to "may" resolves my concerns.

-- 
Best Regards,
Rumen Kyusakov
PhD student 
EISLAB, LuleƄ University of Technology


On Wed, 2012-11-07 at 14:20 -0800, Takuki Kamiya wrote:
> Hi Rumen,
> 
> Thank you for your comments on EXI Profile Last Call Working Draft.
> We appreciate both your interest in our work and feedback on the document.
> 
> The EXI WG agrees to the suggestion lessening the compliance requirements
> of the explicit/implicit parameters communication from "should" to "may".
> 
> We are going to make this change understanding that while there are 
> cases that find the sharing of the parameters useful, there are some
> others that do not need to be informed with the parameters values.
> 
> Hope this helps,
> 
> taki
> 
> 
> > 
> > Subject: The Profile parameters
> > 
> > Section: 4. Parameters representation
> > 
> > Paragraph: "In such a case, the actual profile parameters (or fine-grained capping strategies)
> >  should be defined by an out-of-bound mechanism."
> > 
> > Comments:
> >  The maximumNumberOfBuiltInElementGrammars and localValuePartitions parameters should not be
> >  mandatory to be set/communicated-out-of-bound in my opinion. For the number of build in grammar
> >  the encoder knows the number of the grammars so no need to be included in the header. On the
> >  decoder side if the implementation is "smart" it won't create a new build-in element grammar
> >  before examining the next event. If it is a xsi:type="SOME_EXISTING_TYPE", there is no need to
> >  create a new build-in element grammar.
> >  For the localValuePartitions again - no issues for the encoder if the parameter is not included in
> >  the header. The decoder on the other hand can create local value tables only if it has enough
> >  memory to do so. If it cannot support local value tables, it will only expect string values
> >  represented literally in the stream. Receiving a string as a compact identifier will produce error
> >  during decoding in any way if the decoder does not have enough memory.
> > 
> 
> 
> 
Received on Monday, 12 November 2012 10:28:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:45:28 UTC