Call for consent: csprd01 comment 035, 037, and 056: changes to the Change Track module design

[Ryan King <ryanki@microsoft.com>]

After today’s TC conference call and discussions on referencing and segmentation, I am changing this proposal to the following:

 

Regarding csprd01 comment 056: I propose that we make the following changes:

 

1.      Allow <ctr:changeTrack> at <file>, <group>, and <unit>

2.      In the descriptions for G.1.2.2 changeTrack, G.1.2.3 revisions, G.1.2.4 revision, and G.1.2.5 item:

a.      Change “...associated with the enclosing element.” to “…associated with a sibling element, or a child of a sibling element, to the change track module within the scope of the enclosing element.”

3.      G.1.3.1 appliesTo

a.      appliesTo – Indicates an XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element. indicates the XLIFF element to which the change track information applies.

b.      Value description: Any valid XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element. Any valid XLIFF element name.

Regarding csprd01 035 comment [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.

1.      Rename nid attribute to ref

2.      Reword the already existing Processing Requirement to “When the appliesTo attribute refers to a child element that is a multiple instance within the enclosing parent element, the nid ref attribute must be used to reference an individual instance if and only if the referenced instance has an id.”

Regarding csprd01 037 and 035 comment [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.      Remove the checksum attribute from the module. It was discussed during the segmentation discussion that as long as there are extension points for the revision (and there are) it can be left up to the processing agents to add a checksum, a hash id, or other means as deemed appropriate to the processing agent.

If anybody has suggestions or objections to these changes, please let me know by 09 July. Otherwise, I will consider these issues resolved, and update the spec.

 

Thanks,

Ryan

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Monday, July 1, 2013 11:54 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] csprd01 comment 056: changes to the Change Track module design

 

Regarding csprd01 comment 056: I propose that we make the following two changes:

 

1.      Allow <ctr:changeTrack> on the following additional extension points: <file> and <group> as it can potentially store change track information for any valid XLIFF element within the scope of the element where it is contained.

2.      Remove the following text from “used in” for the checksum attribute: “any XLIFF element that accepts attributes from any namespace.” The following attributes: author, datetime, and checksum appear on <source>, <target>, and <notes>, in the change tracking examples, but this is implicitly allowed by those elements being extensible, so does not need to be specified explicitly on the attribute itself.

 

Thanks,

Ryan