[OASIS Issue Tracker] (XLIFF-4) Simplify Change Tracking Data Model

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/XLIFF-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65157#comment-65157 ] 

David Filip commented on XLIFF-4:
---------------------------------

In reply to Yves comment from 12/Dec/16 1:14 PM

If the preference is to be able to validate the Revision by xsd rather than scehmatron, we need to sligtly change the strcuture to be able to enforce exactly one of contentItem, segmentItem, or unitItem, but allow any number of item elements.
Now
Revision
Contains:
At most one <xlf:originalData> element followed by
Zero, one, or more <item> elements followed by a choice of:
Exactly one <contentItem> or
Exactly one <segmentItem> or
Exactly one <unitItem>
elements.

This means enforcing all item elements before the more complicated elements

We had before:
Revision
Contains:
At most one <xlf:originalData> element followed by
One, or more of
<item> or
<contentItem> or
<segmentItem> or
<unitItem>
elements.
This would allow an arbitrary order but would require additional Constraints and Schematron rules to enforce uniqueness of the more complex item types.

Please express your dissent by Friday EOD. If no dissent expressed before weekend I will call for dissent on the XSD friendly solution in the meeting of Feb 7 2017.

> Simplify Change Tracking Data Model
> -----------------------------------
>
>                 Key: XLIFF-4
>                 URL: https://issues.oasis-open.org/browse/XLIFF-4
>             Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
>          Issue Type: Improvement
>          Components: Change Tracking Module
>    Affects Versions: 2.1_csprd01
>         Environment: https://lists.oasis-open.org/archives/xliff-comment/201610/msg00015.html
>            Reporter: Yves Savourel
>            Assignee: David Filip
>              Labels: work_required
>             Fix For: 2.1_csprd02
>
>
> It seems to me the new model for change tracking is too complicated to be implemented without a) a lot of efforts and b) mistakes.
> Having different types of content in <item> and <simpleItem> based on the property attribute and the grand-parent element's
> appliesTo attribute is not going to make things easy.
> I would propose to simplify things:
> If the change is on the content of a <source> or <target>:
> -> Use a <contentItem> element that contains text and zero or more inline codes (same as a source or target content)
> If the change is on the content of a <unit> (e.g. segmentation):
> -> Use a <unitItem> element that contains one or more <segment> and zero or more <ignorable> (same as in <unit>)
> In all other cases:
> -> Use an <item> element that has plain text
> - Neither <contentItem> nor <unitItem> would have a property attribute, or if they do it would be default and fixed to 'content'.
> - The property in <item> could be set to 'content' only if the revisions' appliesTo is 'note'
> As for dealing with orphan <sm/> and <em> in <contentItem>: I would propose to make them <mrk> with a new CTR attribute
> ctr:added='sm|em' to indicate that the original was either a <em/> (added='em')or a <sm/> (added='sm'). 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)