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

Yves Savourel commented on XLIFF-4:
-----------------------------------

As far as I can tell a <revision> can contain several versions of a content, but only one set of <originalData>. This may cause the same <data> element to try to store different code, or id to be duplicated, or any kind of trouble related to several dataRef pointing to the same place.

So it seems the <originalData> should be stored inside <contentItem> and <unitItem> rather than <revision>, so each item can have its own. And yes, that makes an already very verbose module even more verbose, but I don't see an alternative. Storing snapshots always takes space.

This also means <contentItem> probably need to have an extra element to separate the content from the <originalData> element:

<ctr:contentItem>
 <x:originalData>...</x:originalData>
 <ctr:content>the content</ctr:content>
</ctr:contentItem>




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