Edit comment LC-2709 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-2709

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: Limiting the evolutions of build-in grammars
Section: 2.1 Grammar Learning Disabling Mechanism
Paragraph: "If grammar learning is disabled in the case of a production insertion in a given
grammar, named G, the following rule happens ..."
Comments:
This is the first time the second mechanism (Limiting the evolutions of build-in grammars) is
mentioned in the spec. It is almost impossible to make the connection with the rest of the spec
without reading it few/several times. In my opinion this mechanism should be clearly described and
differentiated with the first one (using xsi:type).
A proper way of doing this is by mentioning it in the 2. Grammar Capping sections and then
describing it as a separate subsection. Giving it a proper name would also help a lot as "grammar
learning is disabled in the case of a production insertion" is definitely not a good one.

Related issues: (space separated ids)

WG Notes:

Resolution: On 2013-02-13, the WG members (including Rumen Kyusakov) agreed to clarify the specification to address the issue. See [4]. ------------------------------------------------------------------------------- On 2013-02-12, Rumen Kyusakov reflected further and responded in [3]: Please consider adding the following paragraph to the "2. Grammar Capping" section: The arbitrary memory growth at runtime when processing EXI streams is due to indexing QNames and string values for frequent use (string tables growth) and adapting the processing strategy to unknown input in case of schema-less encoding or deviations from the schema (build-in element grammar generation and evolution). The EXI Profile provides mechanisms to restricts the growth of the string tables and the grammar evolution in order to predictably limit the memory growth at runtime. Limiting the size of the string tables and the grammar evolution bounds the memory growth but also increases the size of the event codes required for encoding unknown input such as schema deviations hence leading to less compact EXI streams. Some mechanisms to lower the memory usage are already available in the EXI 1.0 specification and should be considered in conjunction with the EXI profile (see B Guidelines (Non-Normative)). For example the EXI specification provides a mechanism to limit the memory growth due to global value string table by using the valuePartitionCapacity. The local value string table can only be disabled if the global value string table is also disabled by setting the valuePartitionCapacity to 0. The Local Value Capping mechanism described below allows for disabling the local value table even if valuePartitionCapacity is greater than 0. According to the EXI 1.0, an EXI processor creates a new build-in element grammar for each unknown element it encounters. The EXI profile limits the number of build-in element grammars created at runtime by using schema informed complex ur-type grammars instead. Each build-in element grammar that is allowed to be created by the EXI profile processor can further evolve by insertion of new productions and hence leads to memory growth during runtime. For that reason, the EXI profile defines a mechanism to limit the number of dynamically inserted grammar productions in the build-in element grammars if such are allowed during processing. The disabling of the local value table, the number of build-in element grammars created at runtime and the number of dynamically inserted grammar productions are all controlled by a set of Profile parameters described in "4. Parameters representation" section. ------------------------------------------------------------------------------- On 2012-11-12, Rumen Kyusakov responded in [2]: I still find the text hard to read and confusing although the changes you suggest are helping a lot. I don't understand this part of your response: > The second means, which is less efficient, should be used whenever the > first mechanism is not available, namely: > > · For AT(xsi:type) attributes > > · For elements being processed using built-in grammars and > within which memory cap is reached Isn't it so that AT(xsi:type) means is not available only in case of schema-less EXI streams? Maybe I'm missing something. I'm also thinking isn't it better to explicitly specify when the second means (using only second level productions) SHOULD be used - using formal SHOULD and not the advisory form "should"? One more comment: I somehow had the feeling that the second means is also applicable to the Built-in Fragment Grammar (http://www.w3.org/TR/2011/REC-exi-20110310/#builtinFragGrammars). Reading your comments I realized that the EXI Profile does not say anything about the limiting the evolution of Built-in Fragment Grammar. The same principle can be applied there as well but if decided not to maybe it is better to explicitly say that the learning mechanisms of the Built-in Fragment Grammars are not disabled. ------------------------------------------------------------------------------- On 2012-11-12, the EXI WG responded in [1]: Here are the two proposed changes, all in section 2: 1. Add the following sentence at the end of the first paragraph: Whenever using the xsi:type attribute switch is not feasible, EXI events of a given element may be represented using only second level productions. Given that this approach is generally less efficient, the xsi:type attribute switch should be used wherever possible. 2. Change: “Note that the EXI profile can only limit grammar for schema-informed EXI streams but…” To: “Note that xsi:type attributes may be used to limit grammar learning only for schema-informed EXI streams and…” [1] http://lists.w3.org/Archives/Public/public-exi-comments/2012Nov/0002.html [2] http://lists.w3.org/Archives/Public/public-exi-comments/2012Nov/0007.html [3] https://lists.w3.org/Archives/Member/member-exi-wg/2013Feb/0013.html [4] https://www.w3.org/2013/02/13-exi-minutes.html#item04

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