AW: LCWD: Canonical EXI

Hi Josh,

Thank you very much for thoroughly reading the document and for your valuable feedback.

Please find inline our response,

Thanks,

-- Daniel


> http://www.w3.org/TR/2015/WD-exi-c14n-20150521/
>
> This document doesn't explain what is normative/informative.
> I'd guess that Notes and A/B/C aren't normative, but there doesn't
> seem to be text to that effect.

Thank you for pointing us to this issue.
The updated draft will label the appendices "Design Decisions", "Canonical EXI Examples", and "Canonical EXI Applications" as non-normative.


>>          C.2.2 Option 2 - Uri scheme fragment identifier
>
> URI is usually written as such.

Fixed.


>> On the contrary, values that match the default value (i.e. <blockSize>1000000</blockSize>) MUST be omitted.
>
> On the contrary => conversely

Agree.

>> When the alignment option compression is set, pre-compress MUST be used instead.
>
> instead of ?

The bullet list item has been changed to "When the alignment option compression is set, pre-compress MUST be used instead of compression."
Further, references to all EXI options have been added.

>> Moreover, the EXI event sequence of each nested element MUST be SE followed by EE
>
> would it hurt you to link "SE" and "EE" to some definition of "Start
> Element" / "End Element" for readers less familiar w/ the jargon used
> herein?

Start Element (SE) and respectively End Element (EE) is used instead of the abbreviations.
A link to EXI event types has been added also.

>> The user defined meta-data MUST NOT be used unless it conveys a convention used by the application.
>
> "user defined meta-data" is italicized, but it isn't linked, and the
> use of "The" doesn't help me. If you dropped "The", I could almost
> understand what you're saying. If the "The" is important, then this
> italicized text SHOULD link to something defining it.

"user defined meta-data" links now to the EXI specification.

>> The user defined meta-data conveys auxiliary information and does not alter or extend the EXI data format.
>> Hence it deemed acceptable to omit this information.
>
> it => it is | it was

Changed to "it is".

>> Elements that are necessary to structure the EXI options document according to the XML schema
>> (i.e. lesscommon, uncommon, alignment, datatypeRepresentationMap, preserve and common)
>> MUST be omitted unless there is at least one nested element according to the previous steps.
>
> Ideally steps are in numbered form, or somehow called out beyond "by
> the way, I hid steps somewhere before this point".

The bullet list has been changed to a numbered list.

>> For Start Element events the order is as follows:
>> SE( qname )
>> SE ( uri : * )
>> SE ( * )
>> For Attribute events the order is as follows:
>> AT( qname )
>> AT ( uri : * )
>> AT ( * )
>
> Is there a reason that there's no space before the `(` for qname, but
> there is a space for the other two `(`s?

No. It is a mistake which has been fixed. Thanks!

>> Optimizations such as pruning insignificant xsi:type values (e.g., xsi:type="xsd:string" for string values)
>> or insignificant xsi:nil values (e.g., xsi:nil="false")
>> is prohibited for a Canonical EXI processor.
>
> I think:
> is => are

Agree.

>> where the rules of determining equivalence is described below.
> is => are (?)

Agree.

>> Further, a String value MUST be represented as string value hit if possible.
>
> `hit` is used three times, only locally. It should either be defined
> or linked to something.

Thanks for the hint. The terminology has been aligned with the EXI specification that uses "when a string value is found in the global or local value partition" and a reference has been added.
http://www.w3.org/TR/exi/#encodingOptimizedForMisses

The new text reads as follows
"In EXI a string value content item is assigned to two partitions, a "local" value partition and the global value partition (see Partitions Optimized for Frequent use of String Literals[LINK]). When a string value is found in the global or "local" partition, it may be represented using a compact identifier. In Canonical EXI a string value MUST be using a compact identifier if possible. Unless the convention used by the application dictates differently (e.g., EXI Profile parameter localValuePartitions set to "0"), EXI processors MUST first try to use the "local" compact identifier and only when this is not successful the global compact identifier. "


>> The canonical representation dictates that characters from the restricted character set MUST use
>> the according n-bit Unsigned Integer.
>
> "according n-bit Unsigned Integer" sounds weird. If it's defined
> elsewhere, please link. If not, please explain. (Or "according" could
> be the wrong word.)

The link to http://www.w3.org/TR/exi/#encodingBoundedUnsigned has been added.

>> A rationale for each decision is given as well as background information is provided.
>
> as well as => and

Agree.

>> EXI can be used in such use cases and offers benefits w.r.t. compact data exchange and fast processing.
>> To ensure that relevant Infoset items are available the following
>> EXI Fidelity Options must be always enabled:
>> Preserve.pis, Preserve.prefixes, and Preserve.lexicalValues.
>> When the XML canonicalization algorithm preserves comments
>> the EXI fidelity option Preserve.comments must be also enabled.
>
> //This almost feels like normative instruction, and I don't recall
> similar instructions in the main document.
> //If similar instructions do exist in the main document, a pointer
> would be appreciated.

The Canonical EXI documents does not want to tackle XML. Instead it deals with EXI only and this section is just a recap of information shared in our best practice document. A pointer to this document is added (see http://www.w3.org/TR/exi-best-practices/#signature)

> I've decided the following is the block could benefit from emendation:
>
> Canonical XML is designed to be useful to applications that test whether an XML document has been changed (e.g., XML signature).
>
> I read the "is" here as indicating it was something defined in this
> document. I think this text is actually referring to something beyond
> this document, in which case, I'd suggest:
>
> is => was
>
> Alternatively you could prefix the sentence with "While" or something
> (but that would involve rewriting the end of the sentence)....

Agree. Changed "is" to "was".

> Canonical EXI, in contrast to Canonical XML, deals with EXI documents and does not use plain-text XML data and the associated overhead.
>
> the => its

Agree.

>> Example B-3. Example algorithm for converting float values to the canonical form
>
> Example..Example?

Reads now as follows "Example B-3. An algorithm for converting float values to the canonical form"

>> Initialize the exponent with the value 0 (zero) and jump to step 2.
>
> s/. and j/. J/

Agree.

>> If the value after the decimal point can be represented as 0 (zero)
>> without losing precision jump to step 4, otherwise to step 3.
>
> s/precision jump/precision, [then] jump/
> s/otherwise/otherwise jump/

Agree.

>> If the signed mantissa is unequal 0 (zero), unequal -0 (negative zero), and contains a trailing
>> zero jump to 6, otherwise to step 7.
>
> s/zero jump/zero, [then] jump/
> s/otherwise/otherwise jump/

Agree.

>> The canonicalization process of EXI
>> bases upon
>
> awkward

"is based on" used instead.

>> the knowledge of the used EXI options which is an optional part of the EXI header.
>> These options communicate the various EXI options that have been used to encode the actual XML information with EXI and
>> are crucial to be known.
>
> awkward

changed "crucial to be known" to "essential".

> This sections
> section => section | This => These

Agree.

>> provides some best practices - so that for example it can be successfully used as part of the digital signature framework or in other use-cases.
>> Currently different options are discussed.
>
> "discussed" or "under discussion" or ??
>
> i.e. awkward

Changed to "Different options are discussed below."

Moreover, the entire paragraph has been updated to

"The canonicalization process of EXI is based on the knowledge of the used EXI options. The EXI options communicate the various options that have been used to encode the actual XML information with EXI and are essential for any EXI processor. Given that the presence of EXI options in its entirety is optional in the EXI header, the following subsections provide and discuss best practices how to exchange them - so that for example it can be successfully used as part of the digital signature framework or in other use-cases. "

Received on Tuesday, 23 June 2015 14:54:12 UTC