Edit comment LC-2711 for Efficient Extensible Interchange Working Group

Quick access to LC-2705 LC-2706 LC-2707 LC-2708 LC-2709 LC-2710 LC-2711 LC-2712 LC-2713 LC-2714 LC-2715

Comment LC-2711

Comment Shortname:

Commenter: Rumen Kyusakov <rumen.kyusakov@ltu.se>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeAbstract Status of this Document 1. Introduction 2. Grammar Capping 2.1 Grammar Learning Disabling Mechanism 2.2 Grammar Learning Disabling Parameters 3. Local Value Capping 4. Parameters representation A References B Header Considerations (Non-Normative) C Prefix Workarounds (Non-Normative) D Name Table Workarounds (Non-Normative) D.1 Name Table Encoder Workarounds D.2 Name Table Decoder Workarounds E Grammar Restriction Considerations (Non-Normative) E.1 Grammar Restriction Encoder Considerations E.2 Grammar Restriction Decoder Considerations
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody Bournez, Carine Brutzman, Don Cokus, Michael Fernández, Javier D. Heuer, Joerg Käbisch, Sebastian Kamiya, Takuki Kuntschke, Richard Matsukura, Ryuichi McGregor, Don Peintner, Daniel Quin, Liam Shah, Grishma ZERGAOUI, Mohamed

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

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.

Related issues: (space separated ids)

WG Notes: Make sure the editors take care of the change in section 4. The change is not in place as of 2012-11-12.

Resolution: 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.

(Please make sure the resolution is adapted for public consumption)