Re: Common response for LC-2707 and LC-2709

Hi Youenn, 

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.

-- 
Best Regards,
Rumen Kyusakov
PhD student 
EISLAB, Luleå University of Technology


On Mon, 2012-11-12 at 09:57 +0000, FABLET Youenn wrote:
> 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…”
> 
>  
> 
>  
> 
>  
> 
>

Received on Monday, 12 November 2012 12:55:56 UTC