Common response for LC-2707 and LC-2709

Hi Rumen,



Thanks for your valuable feedback.

Please find answers related to points 3 and 4 of your comments.

Please let us know whether that handles your concerns.

Regards,

                Youenn

> 3)

> Section: 2. Grammar Capping

> Paragraph: Whole section

>

>  Comments:

>  In the grammar capping section it is given a single mechanism to

> limit the number of build-in grammars by using the xsi:type attribute

> (possibly with xsd:anyType). There is no mentioning of the second very

> distinct mechanism described later on: limiting the evolutions of

> build-in grammars by restricting the number of dynamic productions inserted. Mixing up between these two mechanisms in the spec is the main source of confusion for me.

>

> 4)

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



First, let me clarify how the profile is expected to work.

EXI profile streams are fully conformant EXI 1.0 streams.

That constraints the means that we can use to restrict grammar learning to two means.

The first means is the use of AT(xsi:type).

Since it is efficient in terms of compression and processing, this is the preferred approach.

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

Since the EXI profile links how the two means are used, we think it still makes sense to group them as a single mechanism.



Based on your comment, we think that the document should be further clarified.

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..."