RE: ITS mapping in XLIFF - annotation in mrk vs original inline codes

> from David:
> Yves, I see one big issue here. And this is at the XLIFF side.
> There was a big pushback in the TC against making core inline elements extensible.
> We have succeeded in making mrk extensible based on the reasoning 
> that it is a generic annotation  vehicle unlike the other inlines.

This is not extensibility: it's just adding module-specific attributes.
Several attributes have added to inline elements for the other modules, why not for the ITS module?


> from David:
> Also I would concentrate on XLIFF 2.x mapping long term 
> rather than XLIFF 1.2

Tilde's files are 1.2: if we must concentrate on something it's 1.2


> ...and XLIFF 2.0 does have the provision 
> for splitting markers..

Whatever 2.0 allows doesn't help the 1.2 files we have today.
And not being able to have overlapping <mrk> is not the only reason to use ITS directly in <g>/<bpt> anyway.


> from David:
> This should be resolved real soon, not to impede Tilde.

I think the priority MUST be to get the mapping right and SHOULD be to get it done fast.


> from Dave:
> To clarify, would we still need to use ITS 
> annotation with mrk in cases where:
> a) mtype="seg" since this is inserted by the XLIFF extractor
> b) the annotation was added after the XLIFF file was generated 
> from the source, e.g. by an XLIFF conformant terminology tool, 
> since <g> and <bpt> as I understand relate specifically to 
> inline annotations in the source file, and thus a reference to 
> the skeleton.
> If (b) is indeed the case, then the mapping get more complex since 
> one has to support both cases, g/bpt and mrk, but you would still 
> avoid having them both together as in your example.

Yes, this would not prevent to use ITS in <mrk> when it make sense.

Note also that this would not affect Tilde's implementation too much, since TAWS mostly *adds* annotations to the existing XLIFF document, they should use <mrk> most of the time anyway.
The only thing TAWS would have to be careful with is to check if a term is not already marked up (either with <mrk> or with <g>/<bpt>).

Essentially I'm just saying that if the ITS annotation already exists in the original code it may make sense to put the ITS attributes in the elements that carry the original annotation rather than add a new layer.

BTW David: For 2.0 things like slr:sizeRestriction exist in <pc>/<sc> (the equivalent of <g>/<bpt>). To me that indicates an intent to allow coding information such as ITS Storage Size directly in the element representing the original code when possible. Why this would be OK in 2.0 but not 1.2?


The parts that bother me are more for things like Terminology or Localization Note where there are native XLIFF ways to set them using <mrk>. So using native ITS attributes would prevent compatibility. (but the question is how many tools are actually using those 1.2 features?)

The part that worries me with always using <mrk> is that it is likely to cause trouble with quite a few tools that are not really handling those extra <mrk> very well because they have not been really used in 1.2 until now. TM matching, merging, etc. are example of operations where un-expected <mrk> are likely to cause problem.
But I suppose this is the tool's problem rather than XLIFF 1.2's problem.

Using always <mrk> or using <mrk>/<g>/<bpt> have both their share of issues and advantages overall. Depending on where you are in the tools chain and what you do one or the other is better.

-ys

Received on Wednesday, 15 May 2013 11:57:15 UTC