Public document·View comments·Disposition of Comments·
Efficient Extensible Interchange Working Group Other specs in this tool
In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.
In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.
Commentor | Comment | Working Group decision | Commentor reply |
---|---|---|---|
LC-2709
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
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 |
yes |
LC-2711
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
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. |
yes |
LC-2706
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
As alluded in my previous emails, the next updated version of the profile will introduce a "Guidelines" section. In regard to restricted devices, this new section is going to give advice for sensible default options for both, the EXI profile and the EXI1.0 baseline spec. However, we do not plan to prohibit users experimenting with the various options to best fit their needs. http://lists.w3.org/Archives/Public/public-exi-comments/2012Dec/0000.html |
tocheck |
LC-2707
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
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 |
yes |
LC-2708
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
http://lists.w3.org/Archives/Public/public-exi-comments/2013Jan/0000.html | tocheck |
LC-2710
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
http://lists.w3.org/Archives/Public/public-exi-comments/2012Nov/0003.html | tocheck |
LC-2712
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
> All the paragraph could be summarize by saying that the application should > use only ONE prefix per namespace. Then the two requirements are fulfilled. Your statement is actually not entirely equivalent to the statement in the current specification. Let’s take the following example: <A> <B xmlns:ns1=”uri1”/> <B xmlns:ns1=”uri1”/> </A> The following document would match your statement but not the one in the specification. In particular, the second prefix would be encoded as an index. A decoder may not be actually able to give to the XML layer the knowledge for that second namespace declaration. In addition, this requires two namespace declarations, which can be optimized in terms of compression as follow: <A xmlns:ns1=”uri1”> <B/> <B/> </A> That is why we prefer to keep the more restricted statement in the specification. |
yes |
LC-2713
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
> Subject: Striping of Profile xsi:type attributes > Section: E.2 Grammar Restriction Decoder Considerations > Paragraph: "An EXI profile decoder SHOULD strip any xsi:type attribute with > the xsd:anyType value from the infoset that corresponds to the grammar > learning disabling mechanism." > Comments: > It is strange to have "SHOULD" in a (Non-Normative) section. In any case > a non-Profile EXI decoder will include the Profile xsi:type attributes. > Your comment is correct. We therefore propose to replace uppercase SHOULD by lowercase may. |
yes |
LC-2714
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
As alluded in my previous emails, the next updated version of the profile will introduce a "Guidelines" section. In regard to restricted devices, this new section is going to give advice for sensible default options for both, the EXI profile and the EXI1.0 baseline spec. However, we do not plan to prohibit users experimenting with the various options to best fit their needs. http://lists.w3.org/Archives/Public/public-exi-comments/2012Dec/0000.html |
tocheck |
LC-2715
Rumen Kyusakov <rumen.kyusakov@ltu.se> (archived comment) |
|
As alluded in my previous emails, the next updated version of the profile will introduce a "Guidelines" section. In regard to restricted devices, this new section is going to give advice for sensible default options for both, the EXI profile and the EXI1.0 baseline spec. However, we do not plan to prohibit users experimenting with the various options to best fit their needs. http://lists.w3.org/Archives/Public/public-exi-comments/2012Dec/0000.html |
tocheck |
LC-2705
Yusuke DOI <yusuke.doi@toshiba.co.jp> |
|
A new appendix section, "C.2 Implementation Strategies" will be added that sketches different strategies regarding an EXI header options parser: * bit matching * partial EXI Options grammar parser * mix * full |
tocheck |