[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Call for consent: csprd01 comment 035, 037, and 056: changes to the Change Track module design
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.”
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.
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.
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
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 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]