RE: [xliff] Call For Dissent: Inline Markup within Change Tracking <item />

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

> Phil: It is very narrow improvement for our use case, which is on preventing the loss 
> of inline markup after track changing in OCELOT. So we aimed to fix this bug, 
> which created more questions on the scope of the CTR module. 
> 
> dF: It might be good to allow Track changes up to <unit>, to capture segmentation revision. 
> So if the segmentation not changed, only the occurred modifications will be recorded. 
> But, as you can not reference target (source) elements, the revision must be recorded 
> at least from <segment> (which allows @id). Phil has provided a modified XSD, Tom, 
> have you had a look?
>
> Tom: Not yet. I'll have to look more closely at it. If what's in Phil's version of 
> the XSD is complete, it's just copying to the production XSD.
>
> dF: At least <segment> must be allowed in CTR, we could discuss allowing of <unit>.


I don't think having <item> be a container like a <source> or <target> would be a good idea: It would makes the object model quite
difficult to work with. Allowing to track <unit> using <item> would be even more challenging.


On a related note:

I'm also not quite sure what to make of the currentVersion attribute. It "...holds a reference to the most current version of a
revision." But what does it mean? What is the "most current version"? The latest? The version just before the current content/?

Are we supposed to have copies of the current content/values? (The example 5.6.6 of the 2.0 specification seems to show we have
copies of the current content in the revisions). I think this is not something we want to do: Having several copies of "the latest"
of something is always a problem: For example: What if a tool modifies the true content but does not update the revisions? We end up
with a "currentVersion" that is not the latest.

By the way, the version numbering in the example doesn't make sense to me: r1 is the latest, while r2 and r3 are previous revisions.
Logically it should be r1 the oldest revision and r3 the latest.

Cheers,
-yves