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

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

1)
If Yves, and other users/implementers think that the proposed data model is easier to implement, we can go for. It's not a MUST change IMHO, as the same things can be expressed by the data model currently in the spec and by the proposed one. The current design was inspired by what Chase said when discussing it in the XLIFF OMOS TC, and it was kind of an attempt to recreate the change tracking capability of XLIFF 1.2 <alt-trans>.
Again it's a relatively big change and will have impact also on xsd and Advanced Validation if we go for it. Still I think we can go for it if people think it's easier to implement. Unless something strange comes up when elaborating it in detail.

2)
On the other hand I propose not have a mechanism to replace orphaned start or end markers with a ctr-pseudo-completed mrk. If you need to orphan a marker or code you should consider tracking the unit rather then the target.

On the other hand in case your change did not affect the marker based annotation, we could think of adding a PR to drop annotations to prevent their malformation.
Anyways, I think that the tracking should be done verbatim and the number of transforms should be minimized (to zero if possible) to increase usefulness, e.g. for rollback or comparison capability..

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