- From: Rumen Kyusakov <rumen.kyusakov@ltu.se>
- Date: Mon, 12 Nov 2012 11:28:33 +0100
- To: public-exi-comments@w3.org
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