[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=64675#comment-64675 ] 

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

Thanks Yves, what you described sounds as a choice of sequences (with a given order) I think that there is no need to do that on the xsd level.
The current text IMHO corresponds to a choice group of all item types (this is also in xsd) and the content and unit items don't need to go first. However, due to the revision constraints there must not be more than one of the higher level items.
It think it's OK to have a schematron test to ensure that at most one contentItem or unitItem is present
@Soroush, do we test for that at the moment?

> 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: request_tc_discussion
>             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)