RE: csprd01- 35 Change Tracking Module Design

[Ryan King <ryanki@microsoft.com>]

Hello Chase,

 

Regarding your comment on the change tracking module in the recent public review of the XLIFF 2.0 spec:

 

[1] This is mostly a matter of preference, but I don't like the ad-hoc referencing mechanism used to attach revision data. I would prefer to see a more robust system based on RDF or something similar. [2] No processing restrictions are given for the nid attribute. It is strange that for example appliesTo could specify "note", but nid could be absent. In this case, it would not be clear what note the revision refers to. [3] The stated purpose of the @checksum attribute is to detect changes in the revision data from non-compliant parsers. In that case, why not have checksums on the source content itself (or match proposals, etc)? It seems strange to only place this protection here.

[1] Thanks for your feedback, but it was decided to stay with the current implementation.

[2] is already taken care of by an existing processing requirement (note the attribute was renamed from nid to ref):

·         When the appliesTo attribute refers to a child element that is a multiple instance within the enclosing parent element, the ref attribute must be used to reference an individual instance if and only if the referenced instance has an id.”

[3] For the sake of enabling re-segmentation in a <unit> it was decided to remove the checksum attribute from the module. However, because there are extension points in most elements, it can be left up to the processing agents to add a checksum, a hash id, or other means as deemed appropriate to a user’s tools and processes to allow for this.

Thanks,

Ryan