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

Hi David, all,

> The relationship between ITS Translate and XLIFF Translate is not
> as simple as you suggest.
> You yourself specified on the wiki that translate can be implemented as 
> non extraction or hiding of stuff in codes.

I think you are mixing up two aspects: 1) How to extract data marked up with ITS and 2) how ITS is represented in XLIFF.

I agree that the first part is not normative from the viewpoint of the XLIFF specification: It's a guideline.

But the second part should be normative: if we don't define normatively ITS Translate in XLIFF, then an ITS processor or an XLIFF processor looking at ITS information cannot know for sure how to get the Translate information.

Take a better example, Localization Note:

Based on the discussion of last week, it seems we probably do not need to have an itsm:locNoteType. So that data category would fall into the class "Available through XLIFF core", which currently is not normative. But if we do not describe *normatively* how the Localization Note's type is represented for a comment annotation, anyone can decide to add their own attribute to have that type specified in the <mrk> element instead of using a reference to a <note>.

By point is: The description of how ITS information is represented in XLIFF must be normative for all data categories (Even if it is to say: the representation in XLIFF for this data category is not addressed in this version).

So I think a single section (maybe call it "ITS representation" if "ITS module" seems to be too narrow) that lists all the data categories is the best way to do this.

And for the "extraction guidelines", you are right: an appendix would do. Looking at time constraints, maybe the focus should be on the normative ITS section.

The initial wiki page is a mapping, which includes both the guideline and the representation.

Cheers,
-yves

Received on Tuesday, 25 November 2014 13:04:06 UTC