RE: Concise Format for EXI Grammar

Hi Yosuke,

The EXI specification specifies abstract grammar for EXI, and how it binds to 
XML Schema.

Although section 8.5.4 specifies a normative way to generate grammars given 
a schema, it is normative only in the sense that an implementations needs to 
produce encodings *as if* it was using the exact grammars generated by the 
method described in the spec. The paragraph that explains this is exerpted 
below from section 8.5.4:

"The algorithms expressed in this section provide a concise and formal 
 description of the EXI grammars for a given set of XML Schema definitions. 
 More efficient algorithms likely exist for generating these EXI grammars and 
 EXI implementations are free to use any algorithm that produces grammars and 
 event codes that generate EXI encodings that match those produced by the 
 grammars described here."

In other words, "EXI grammar" is just a denomination, a designation, 
a conceptual term that merely *depends* on the example "method"
described in the spec.

For example, OpenEXI [1] contains two EXI implementations (Milinda and Nagasena)
each using fundamentally different way to compute and deliver grammars. 
Milinda uses a novel technique to generate schema-informed EXI grammars from 
schemas whereby the number of grammar state objects generated is roughly the 
same as that of schema constructs such as elements, types and groups regardless 
of minOccurs/maxOccurs constraint numbers given to particles in the schemas.
Nagasena, on the other hand, uses the algorithm specified in the EXI 
specification to generate schema-informed EXI grammars. Unlike Milinda, the 
number of grammar state objects is additionally affected by minOccurs/maxOccurs 
numbers given to particles.

Milinda and Nagasena were implemented by the same developer. They both have
grammar serialization format. Nevertheless, it is technically not feasible
to feed one serialized grammar into the other implementation. They are just 
fundamentally very different.

The good news is that Nagasena's grammar format is independent of programming 
languages. EXI implementors who seek direct access to grammar knowledge 
without dealing with grammar's binding to W3C XML Schema can tap into
Nagasena's serialized grammars.

Sincerely,

[1] http://openexi.sourceforge.net/

taki



-----Original Message-----
From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp] 
Sent: Wednesday, March 07, 2012 6:50 PM
To: Carine Bournez; public-exi@w3.org
Subject: Re: Concise Format for EXI Grammar

Carie,

Thanks for clarification. I don't find apparent interoperability problems so far. My concern is the learning cost before make things work. EXI spec is good and clear I think, but still needs certain amount of effort to understand correctly.

When someone just want to make it work in some field, it's far better for him/her if s/he can start from a pre-compiled grammar. It can be implementation specific, but I don't find a reason to avoid some 'non-normative' reference serialization model. And I believe if we want to make more use of EXI in the world (my concern is on embedded systems), make it easy to start is very effective strategy.

Regards,

Yusuke

(2012/03/08 3:36), Carine Bournez wrote:
> Hi,
>
> On Thu, Feb 09, 2012 at 04:49:12AM +0900, Yusuke DOI wrote:
>> Dear EXI gurus,
>>
>> Is there any intermediate format to describe EXI grammar?
>>
>> As I'm working for several EXI-related projects including SEP2, I'm
>> feeling it's very convenient if we can share EXI grammar in well-defined
>> format. The format used in EXI spec is very descriptive, but I guess
>> that grammar notation is for humans.
>>
>> If there's machine-readable (e.g. in plain text or XML) intermediate
>> format for EXI grammars, I believe we can reduce troubles on
>> spec-understanding stage by sharing a good grammar between
>> implementations. Then people can focus on implementations for various
>> devices of their own.
>
>
> The EXI 1.0 specification does not define a format to exchange grammars
> between processors. It specifies how to build the grammars in a non-ambiguous
> way, so that a grammar exchange is not needed. The grammar notation used in the
> specification is for implementers of EXI processors and it has no
> machine-readable serialization. In some applications it may be interesting
> to define a serialized format of the grammars in use, but such a format
> would be specific to each use case to suit best the application needs.
>
> If you encounter particular interoperability issues about grammars, we
> welcome your feedback and will do our best to clarify the specification
> wording.
>
>

Received on Friday, 9 March 2012 05:52:00 UTC