Comments for xliff 2.2 - unit type support...

[jim]

I know this needs to go to the xliff 2 TC - but wanted to get some comments here:

The upcoming XLIFF 2.2 is being discussed here: XLIFF 2.2 Work in Progress. This would be our chance to make comments and possibly get a feature added.

One issue I have with xliff 2 (this is actually the only one :-)) is that the unit no longer carries with it the notion of paragraph vs linguistic sentence. xliff 1.2 has the concept, though implemented poorly and implied with <source> and <seg-source>, and makes it easy to detect when we need to further segment an xliff 1.2 file (if no seg-source then segmentation is possible).

For xliff 2.x we can do better with extra metadata:

An Interesting Adhoc Solution co-opts the Okapi meta data like this:

1. <unit id="tu3" type="okp:paragraph">
2. <unit id="tu5" type="okp:li">
3. <unit id="tu5" type="okp:title">
4. etc..

I like this approach. As I explain in the ticket link above (Issue #1117) segmenting the unit content is complicated and having the unit meta (paragraph, title, list etc..) can determine if and how we segment.

What I would like to propose to the xliff 2.2 working committee is a more standard way to do this. Defining well defined, standard tags vs defacto tags like Okapi provides.

Thoughts?

I will follow up with the TC.

Jim Hargrave

[jim]

By relying on internal unit or segment content type we could then get rid of the "needsSegmentation" option in the XLIFF2 Filter as we rely on consistent content types and the canResgment flag. Of course we can have simple defaults - maybe that still needs an option. But we can do a better job of explaining it etc.. Currently  needsSegmentation is a kind of mysterious hidden option (for good reasons IMHO since it is not fully working as described in a previous email).

Jim