W3C home > Mailing lists > Public > public-exi-comments@w3.org > January 2013

Response to LC-2708 (EXI Profile)

From: Peintner, Daniel (ext) <daniel.peintner.ext@siemens.com>
Date: Fri, 11 Jan 2013 09:08:24 +0100
To: "public-exi@w3.org" <public-exi@w3.org>
CC: "public-exi-comments@w3.org" <public-exi-comments@w3.org>, "rumen.kyusakov@ltu.se" <rumen.kyusakov@ltu.se>
Message-ID: <1D873F12-EE6D-42DC-AAC2-6F14667C823C@mimectl>
Hi Rumen,

Thank you for your comments on the EXI Profile Last Call Working Draft.

> Subject: Event code length for xsi:type attribute event
> Section: 2.1 Grammar Learning Disabling Mechanism
> Paragraph: "The xsi:type attribute event MUST always be represented by the AT(*) production whose
> event code length is 2."
> Comments:
> I am sure there is a good reason to require this but I cannot deduct it. Maybe a hint in the spec
> will make the job of the implementers easier. My guess is that this is connected to the separation
> of the "original" xsi:type attributes and the xsi:type attributes added because of the Profile.

You are right that requiring "xsi:type attributes be represented by the AT(*) production whose event code length is 2" has a strong reason.

We clarified this circumstance in appendix section  "E.2 Grammar Restriction Decoder Considerations" mentioning that this behaviour guarantees that once grammar learning is disabled, the EXI decoder will not need to create any new built-in element grammar. Further, for any such grammar, the EXI decoder can directly deduce the corresponding grammar state from the EXI stream. (see existing explanation regarding bit-packed and byte-aligned mode).

The cited Section 2.1 links to the revised appendix.

Please let us know whether this solves the issue,


-- Daniel
Received on Friday, 11 January 2013 08:09:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:45:29 UTC