W3C home > Mailing lists > Public > public-exi@w3.org > May 2016

RE: Canonical EXI - CR Review

From: Takuki Kamiya <tkamiya@us.fujitsu.com>
Date: Mon, 2 May 2016 14:23:33 -0700
To: "Peintner, Daniel (ext)" <daniel.peintner.ext@siemens.com>, "public-exi@w3.org" <public-exi@w3.org>
Message-ID: <23204FACB677D84EBD57175AB7B5A71C03BF96F727C5@FMSAMAIL.fmsa.local>
Hi Daniel,

The proposed edits resolve all my commented issues.

Thank you,

Takuki Kamiya
Fujitsu Laboratories of America

-----Original Message-----
From: Peintner, Daniel (ext) [mailto:daniel.peintner.ext@siemens.com] 
Sent: Tuesday, April 26, 2016 12:50 AM
To: Takuki Kamiya; public-exi@w3.org
Subject: AW: Canonical EXI - CR Review

Hi Taki,

Thanks for looking into the document more closely and for providing feedback.

> In the final review before requesting CR transition, I have the following
> comments.
> 1. In section 3, it says:
> -------------------------------------------------------------------------------
> A canonical EXI Options document MUST respect the following constraints.
> 1.The EXI Options elements (i.e. byte, pre-compress, selfContained, valueMaxLength,
>  valuePartitionCapacity, dtd, prefixes, lexicalValues, comments, pis, blockSize,
> compression, fragment, schemaId, strict) that match the default value (e.g.,
>  <blockSize>1000000</blockSize>) MUST be omitted (see EXI specification for default
> values).
> -------------------------------------------------------------------------------
> I am not exactly sure what this paragraph means. For instance, byte element
> does not per se have a default value. In this sense, <byte/> element cannot
> be omitted. Moreover, it is self-evident that <byte/> cannot be omitted because
> omission makes the setting fallback to bitPacked.

I do see the issue. I propose to simplify the constraint as follows given that blockSize is the only option that has an actual default value:

"An EXI Options element blockSize that matches the default value (i.e., <blockSize>1000000</blockSize>) MUST be omitted."

That said, all other options such as byte indicate with their presence a certain intent.
Note: The conflict of certain options (e.g., compression option MUST NOT appear when the "alignment" element is present) is taken care by the EXI spec already.

> 2. In section 4.3.3 Whitespace Handling, it says:
> -------------------------------------------------------------------------------
> Not in all situations it is possible to respect whitespace handling rules.
> For example when the grammar in effect is a schema-informed strict-grammar
> and xml:space is "preserve". The value " 123 " typed as xsd:int cannot
> preserve the heading and trailing whitespace when typed datatype
> representation is used.
> -------------------------------------------------------------------------------
> Is this specific to strict mode?
> If we allow the use of typed CH production, the above note should apply to
> non-strict case.

Good catch. Even if it is just an example we should replace "schema-informed strict-grammar" with "schema-informed grammar".

> 3. I think we should have Acknowledgements section in the Appendix
>   listing all names of WG members, as well as a few ex-members who
>   contributed to the production of this document.

Good comment. I will start listing WG members and will get in touch with Carine for a complete list.

Please let me know whether these updates resolve your issues.


-- Daniel
Received on Monday, 2 May 2016 21:24:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 21:24:16 UTC