Preview of a planned errata clarifying built-in element grammar semantics

Hi,

As many people may have already been already aware, the EXI WG is currently
working on the task of defining an EXI 1.0 profile that aims to describe
a class of EXI 1.0 streams that is more amenable to ultra-constrained devices
either lacking run-time memory allocation capabilities or at best have
extremely limited dynamic memory resources.

In that effort, one of the primary measures we will take is to constrain
the memory space necessary for maintaining instances of built-in grammar
states for processing EXI streams.

The WG has also been engaging in Post-REC maintenance of EXI 1.0 specification
to identify and fix errors and possible sources of different interpretations.
Careful analysis of the EXI 1.0 specification revealed that the semantics
of Built-in Element Grammar [1] associated with AT(*) event type was somewhat
underspecified. In particular, it did not describe the expected behaviour
when AT(*) is used more than once for the same attribute QName very clearly.
This was in part due to our shared assumption that such a usage will rarely
be implemented thus was of relatively low priority for us to spend time
scrubbing any potential issues. Therefore, it was not surprising that we
found that none of the implementations developed by the WG members would 
generate EXI streams in such a manner. Our study in hindsight, however, 
found that such usage is useful worth to be exploited in defining EXI 1.0 
profile for low-resource devices.

The EXI 1.0 profile will be assuming that one or more occurrences of xsi:type
attribute likely match the same built-in element grammar's AT(*) during the
processing of a single EXI stream. Currently, when an xsi:type attribute
matches AT(*), a specific production whose right-hand-side starts with
AT(xsi:type) is added to the grammar regardless whether such addition has
already taken place for xsi:type or not.

The WG believes that xsi:type attribute matching the AT(*) in the same
built-in element grammar for the second time and thereafter should not
lead to duplicative addition of the same production in the built-in grammar.
We also found that this should be introduced as a case specific to xsi:type
instead of a general case applying to all attribute QNames, in order to
reduce the potential impact to the minimum. It is our plan to clarify this
in the errata [2].

Please let us know if there are any comments or questions as soon as
possible.

Thanks,

[1] http://www.w3.org/TR/2011/REC-exi-20110310/#builtinElemGrammars
[2] http://www.w3.org/XML/EXI/exi-10-errata

Sincerely,
Takuki Kamiya
for the EXI Working Group

Received on Sunday, 26 February 2012 22:11:04 UTC