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.

Thanks,

-- Daniel

Received on Tuesday, 26 April 2016 07:50:11 UTC