[LC-2711] The Profile parameters

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 Wednesday, 7 November 2012 22:20:13 UTC