Re: [xliff] ITS module section(s) in the specification

[Felix Sasaki <felix@sasakiatcf.com>]

Hi Yves, all,

Am 04.12.2014 um 13:37 schrieb Yves Savourel <ysavourel@enlaso.com>:

> Hi Felix, all,
> 
>> Looking at Yves’ mockup, there seem to be many parts 
>> that would not be understood by a generic ITS processors, like:
>> 
>> „	• The id attribute is REQUIRED.“ (for terminology)
>> 
> 
> I don't think a generic ITS processor would need to know things like that to work. If it applies the transformation to deal with
> <sm>/<em> and then applies the rules file, it should have all the info it needs.


Sure. My point was only that current ITS processors don’t understand that they should apply the transformation. I am just trying to support the point I think you made at
http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Dec/0006.html
"It about making sure we have XLIFF normative statements about how each ITS data category is represented (or not).“
We want tools processing XLIFF to understand what they need to do. To give a concrete example, Okapi Ocelot is an XLIFF 1.2 editor. It understands also ITS2.0 markup, but you can use it with XLIFF files that don’t have ITS markup at all. If Ocelot is made „ITS module aware“, it will still be an XLIFF editor, implementing the sm / em transformation etc. 

> 
> 
>>> „If the annotation has an itsm:termConfidence attribute, it must 
>>> be within the scope of an itsm:annotatorsRef with the terminology 
>>> annotator set.“ . 
>> Scope here seems to be the unit, not the whole XML file (which it
>> would be for a generic ITS processor).
> 
> I'm not sure I understand the issue.
> The scope here is the scope of the itsm:annotatorsRef. So that attribute could be set on the element where itsm:termConfidence is on
> any ancestor where it is allowed. No?

Yes, you are right, that is no issue indeed.

Best,

Felix

> 
> Cheers,
> -yves
> 
> 
> 
> 
>