RE: Question on "Adding Productions when Strict is False"

Hi Rumen,

> Element-i,0 : AT (*) [untyped] Element-i,0 n.m+2)
>
> It is inserted before "NS Element-i,0   next n.m" production and after
> the "AT (*) Element-i,0    next n.m"
>
> According to my understanding of the specification this productions
> has three parts [...]

Your understanding is correct.

> However, when looking at the EXIficient implementation:
> in the SchemaInformedFirstStartTag class, methods getNumberOf2ndLevelEvents()
> and get2ndLevelEventCode(), the code includes one more production with
> even code with 2 parts:
>
> In the source code this extra production is referred in the comments
> as "AT(invalid)."

Like in most specifications there are different strategies to actually implement a certain behaviour. This is also the case for the source code you cited.

EXIficient creates an event on the second level that links to the available events on the third level. This second level event code part is never meant to be encoded without a subsequently following third level event code part.

However, everyone is free to choose another strategy as long as the result matches the specification.

Hope this helps,

-- Daniel 









-----Original Message-----
From: Rumen Kyusakov [mailto:kjussakov@gmail.com] 
Sent: Wednesday, October 24, 2012 11:27 AM
To: public-exi@w3.org
Subject: Question on "Adding Productions when Strict is False"

Dear all,

I have a question regarding encoding of event codes in schema mode when strict is FALSE.
According to my understanding of
http://www.w3.org/TR/2011/REC-exi-20110310/#addingProductions the second level productions (the productions with even codes with 2
parts)
for the first grammar rule of schema-derived grammars are:

Element-i,0 : EE                                          n.m // Only
if not available already with shorter event code
                   AT(xsi:type) Element-i,0     next n.m
                   AT(xsi:nil) Element-i,0        next n.m
                   AT (*) Element-i,0              next n.m
                   NS Element-i,0                  next n.m // If NS
are preserved
                   SC Fragment                     next n.m // If SC
are preserved
                   SE (*) Element-i,c2            next n.m
                   CH [untyped] Element-i,c2  next n.m
                   ER Element-i,c2                next n.m // If ER
are preserved

However, when looking at the EXIficient implementation:
in the SchemaInformedFirstStartTag class, methods getNumberOf2ndLevelEvents() and get2ndLevelEventCode(), the code includes one more production with even code with 2 parts:

Element-i,0 : AT (*) [untyped] Element-i,0 n.m+2)

It is inserted before "NS Element-i,0   next n.m" production and after
the "AT (*) Element-i,0    next n.m"
In the source code this extra production is referred in the comments as "AT(invalid)."

According to my understanding of the specification this productions has three parts event code that is defined by the following fragment from the spec:

For each non-terminal Element i, j , such that 0 ≤ j ≤ content , with zero or more productions of the following form:

Element i, j :
        AT (qname 0 ) [schema-typed value] NonTerminal 0
        AT (qname 1 ) [schema-typed value] NonTerminal 1
            ⋮
        AT (qname x-1 ) [schema-typed value] NonTerminal x-1 where x represents the number of attributes declared in the schema for this context, add the following productions:


Element i, j :
        AT (*) Element i, j n.m
        AT (qname 0 ) [untyped value] NonTerminal 0 n.(m+1).0
        AT (qname 1 ) [untyped value] NonTerminal 1 n.(m+1).1
            ⋮     ⋮
        AT (qname x-1 ) [untyped value] NonTerminal x-1 n.(m+1).(x-1)
        AT (*) [untyped value] Element i, j n.(m+1).(x)

where n.m represents the next available event code with length 2.

The last production "AT (*) [untyped value] Element i, j n.(m+1).(x)" has three parts and not 2.

Some test with OpenEXI showed that the same extra production "AT (*) [untyped]" with even code with two parts is used as well.

Can someone give me pointers on why we have this extra production?

Best Regards,
Rumen

Received on Thursday, 15 November 2012 08:18:44 UTC