Re: [xliff] Change Tracking 2.1

Yves, all,

working on a possible solution for the revised ctr module.. [will be back with a strawman by Wed worst case, in the meantime you can see the WIP commits]

Now, rediscovering another ctr issue that is perhaps worth addressing at this point.

The issue is that although the module has a reserved fragid prefix ctr, it really cannot be referenced from outside or inside of XLIFF using the XLIFF fragid mechanism, since it has no suitable id or name attribute that could be used as reference according to our prescribed fragid syntax.

<selector>        ::= [<prefix> <prefixSeparator>] <id>

[my proposal to identify the whole module or extension node in case of a missing id was turned down by the TC during the XLIFF 2 reviews and the fragid mechanism cannot be revised now due to our backwards compatibility promise for XLIFF 2.x]

Arguably the module itself doesn't need to be addressable as it has it's own methods for referencing XLIFF core that it tracks. But extensions, either namespace based or mda based might well need to do that, notwithstanding that an external mechanism that wants to use the change track e.g. for reinstating a version or similar would need to do that.

This is also not solvable by extension (an extended id attribute), as we deliberately did not allow referencing of nested extensions or modules, to keep the fragid mechanism simple and away from potentially endless recursion.. The referencable id would simply have to be declared in the ctr module.

At this point, please let me know if there seems to be a requirement to reference the change track data, if positive we should look into having an optional id at some suitable nodes of that module to allow referencing..

Cheers and thanks

Dr. David Filip

===========

OASIS XLIFF OMOS TC Chair

OASIS XLIFF TC Secretary, Editor, Liaison Officer

Spokes Research Fellow

ADAPT Centre

KDEG, Trinity College Dublin

Mobile: +420-777-218-122

On Thu, Sep 8, 2016 at 3:05 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi all,

A summary of where I think we are for the Change Tracking 2.1:
It seems we have two main issues to resolve:

1) The CTR 2.0 <item> element can track only plain text content, possibly eliminating some elements (e.g. content with inline codes,
segments) from being trackable.

2) We cannot identify a given <source> or <target> with the current ref attribute.

Resolving #2 may be simple: We could adjust the definition of ref to indicate that it is either the value of the ID of the element
being tracked, or if such element cannot have an ID, it is the ID value of its parent (e.g. the <segment> or <ignorable> for
<source> or <target>).

To resolve #1 we probably first want to determine what content the module should be allowed to track.

Currently what you can track in 2.0 is relatively vague but we have examples with <source> and <target>. We have also a real
application (Ocelot) using CTR for tracking <source> and <target>. So it seems we should be, at a minimum, be able to store inline
codes and <originalData>.

David made the case for tracking segmentation changes. That would possibly mean an <item> would be able to contain <segment> and
<ignorable>. I'm not sure how we could make work such content along with inline codes without major headache.

Another issue is the case of <sm> or <em> without their corresponding counter-part. While it is not really explicitly said in the
specification, we normally have no isolated <sm/> or <em/> (See http://markmail.org/message/5hqjj2w4fdjtl44y). So we cannot
represent an <item> for a <source> or <target> where an annotation ending or opening would be in a different <segment>.

One possible solution would be to let <item> to be in plain text and just store the escaped representation of the element to track.
That would solve almost all issues, except for how to organize the storage of <originalData> when you store <source> or <target>.
But that solution is really kicking the issues downstream: how would an agent really use such <item>? For example it may want to
restore a previous version of <target>. For that it would have to parse the data associated with <item> on its own, and out of
context.

I'm not sure what solution can really solve all those issues.

Cheers,
-yves

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xliff message