RE: [xliff-comment] Re: [xliff] Version Control Commit by DavidFilip

Hi David, all,

It seems to me the CTR module is becoming rather complicated.

Here are a few things I've noted after a quick look at the latest draft:

=== Issues ===

--- Do we really want to allow agents to track the content of individual inline codes?

That can be done by tracking the parent's content itself (in a much simpler way).

--- You can have revisions that apply to different elements but be inconsistent:

For example, you can have:

...

</revisions>

...

</revisions>

With both tracking the same content (since segment is a superset of target), but there are no way to safely make sense of their history (e.g. datetime is optional so one may not now the order of the changes, the currentVersion of each could be contradictory, etc.) It'd be impossible to really use across different tools, which make the existence of a common module pointless.

The same issue arises with revisions on specific inline codes along with revisions on the source/target content.

One of the things we wanted to achieve with XLIFF 2.x is avoid having different ways to do the same thing. CTR2.1 has many ways to do the same thing.

--- Currently a <revision> can have more than 1 <item> with the same property value. Which means you can have N different changes for the same data at the same time.

--- I'm unsure how attributes work in the case of tracking a segment/ignorable content.

For example, you may have a revision of the state attribute of the segment s1, but have also an item tracking the segments for the unit where that segment s1 is in; and that segment may have a different state. When a tool looks for the history of the state values for s1 what does it do? Look just at the revisions for appliesTo='target' + property='state' or also take into account the state attribute in the item for appliesTo='segment' + property='content'?

--- Having <originalData> inside <item> seems a bad idea: the content of <item> should be same content as <source>/<target>/<segment/etc. It should probably be at the <revision> level.

=== Thoughts ===

Some ideas:

- Make datetime a required attribute. A history without date/time is a lot less useful, and datetime is easy to set for any tool.

- Get rid of currentVersion: If "the most current version of a revision" means "the latest", then a required datetime takes care of this, without having to maintain an extra attribute (and a bunch of PRs). Or maybe I'm missing the point of this attribute.

- Let's not allow to track individual inline codes. I don't think anyone has made that requirement. It would also make things complicated for interoperability since you would have different ways to track them (individually or in content).

- Add a constraint saying the property values of <item> must be unique within a given <revision>.

- It seems we are having too many ways to track the same thing. And/or we try to do too much.

The only obstacle, as far as know, that prevent us to use inline in <item> is that we say <em/> must have its corresponding <sm/>.

But maybe we've been focusing too much (once again) on the XLIFF markup.

The more general issue with content in CTR entries is that we take it out of context (from a markup viewpoint). But the actual data after parsing is what we really need to store. So, if we have this:

We can store it like this:

The other aspect of CTR is that I don't think we can expect all the constraints the normal unit content has to apply in the CTR elements. We will have duplicate ID values, etc.

- As far as the different types of <item> content: I'm not sure we need all the possibilities the draft currently has. Do we have requirements for all of them?

Cheers,

-yves

xliff-comment message