OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Change Tracking 2.1


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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]