W3C home > Mailing lists > Public > public-i18n-its-ig@w3.org > October 2014

RE: [xliff] possible issue with URN prefixes used to define acceptable namespaces in XLIFF 2.1

From: Yves Savourel <ysavourel@enlaso.com>
Date: Thu, 9 Oct 2014 05:48:06 -0600
To: "'Felix Sasaki'" <felix@sasakiatcf.com>
CC: "'Dr. David Filip'" <David.Filip@ul.ie>, <xliff@lists.oasis-open.org>, "'public-i18n-its-ig'" <public-i18n-its-ig@w3.org>
Message-ID: <004a01cfe3b6$e3e34870$aba9d950$@enlaso.com>
Hi Felix,

> what processor do we assume to produce what parts 
> of the mapping? E.g. general ITS processor, 
> XLIFF2.1+ITS2.0 processor, XLIFF2.1 processor?
 
If you mean what processor produces the ITS information in the XLIFF document, I would say it depends:

- An XLIFF Extractor aware of both ITS and the ITS module for any data coming from the original source document.
- An XLIFF Modifier aware of the ITS Module for data generated during the life time of the XLIFF document.
- An XLIFF Merger aware of both the ITS Module and the ITS syntax if any of that data is merged back into the translated document.

As far as versions: I think this is where having the ITS Module in its own namespace is an advantage: if ITS itself changes and
those changes affect the mapping, we can create an updated version of the ITS module.

-ys


-----Original Message-----
From: Felix Sasaki [mailto:felix@sasakiatcf.com] 
Sent: Wednesday, October 8, 2014 9:18 PM
To: Yves Savourel
Cc: Dr. David Filip; xliff@lists.oasis-open.org; public-i18n-its-ig
Subject: Re: [xliff] possible issue with URN prefixes used to define acceptable namespaces in XLIFF 2.1

Hi Yves and all,

thanks a lot for this. I have put your input into the wiki including the rules file
https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Implementing_and_testing_the_mapping

One question, and if we find and answer we probably would also put that into the wiki: what processor do we assume to produce what
parts of the mapping? E.g. general ITS processor, XLIFF2.1+ITS2.0 processor, XLIFF2.1 processor?
The question is also related to the version of ITS. E.g. in ITS2 we dropped ruby and directionality is not up to date. We may
consider a fast update to ITS2.1 incooperating the now stable definitions from HTML5. Would that break the above processor(s)?

Best,

Felix


Am 08.10.2014 um 14:00 schrieb Yves Savourel <ysavourel@enlaso.com>:

> Hi Felix,
> 
>> I assume by "start the mapping" you mean: creating example input and 
>> output files?
> 
> Not quite. I meant "start to write the rules file".
> But starting the test files at the same time would be perfect too
> 
> 
> Maybe things would be clearer for everyone with an example, so see the attached files:
> 
> - allowed-characters.xlf is an XLIFF 2 document with one of the ITS module feature.
> Important note:
> The namespace of the XLIFF core is still 
> "urn:oasis:names:tc:xliff:document:2.0" but the version is 
> version="2.1". This is likely to confuse a lot of people, but there is no way around: It means the namespace of the core has not
changed, but the version of the document is 2.1 so it uses the new ITS module.
> The ITS module is using "itx" as its prefix to try to make things 
> clearer. But technically it should really be "its" as it is the ITS module. We should never have true ITS elements or attributes
in XLIFF (if we have, they would be seen as extensions).
> 
> - its-to-xliff.xml is a start of the ITS/XLIFF rules file. It tell 
> ITS-processors a) the basic info about what to translate and which 
> elements are inline. And it has a rule that maps the ITS "Allowed 
> Characters" data category to the attribute of the ITS module in XLIFF 
> that implement such feature (a brand new one as it does not exists 
> currently)
> 
> Test results for ITS-only processors may be like this (same as for ITS tests):
> 
> /xliff
> /xliff/@srcLang
> /xliff/@version
> /xliff/file[1]
> /xliff/file[1]/@id
> /xliff/file[1]/unit[1]
> /xliff/file[1]/unit[1]/@id
> /xliff/file[1]/unit[1]/segment[1]
> /xliff/file[1]/unit[1]/segment[1]/source[1]
> /xliff/file[1]/unit[1]/segment[1]/source[1]/pc[1]
> /xliff/file[1]/unit[1]/segment[1]/source[1]/pc[1]/@id
> /xliff/file[1]/unit[1]/segment[1]/source[1]/pc[1]/mrk[1]	allowedCharacters="[a-ZA-Z]"
> /xliff/file[1]/unit[1]/segment[1]/source[1]/pc[1]/mrk[1]/@id
> /xliff/file[1]/unit[1]/segment[1]/source[1]/pc[1]/mrk[1]/@itx:allowedC
> haracters 
> /xliff/file[1]/unit[1]/segment[1]/source[1]/pc[1]/mrk[1]/@type
> 
> While test results for XLIFF procssors amy be like this:
> 
> #/f=f1/u=u1/m1	allowedCharacters="[a-zA-Z]"
> 
> 
>> I put some questions in the ITS IG wiki see 
>> https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Testing_t
>> he_mapping once we have resolved them I'm happy to start with file 
>> creation.
> 
> I've tried to answer them:
> https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Testing_th
> e_mapping
> 
> cheers,
> -ys
> 
> <allowed-characters.xlf><its-to-xliff.xml>
Received on Thursday, 9 October 2014 11:48:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:11:31 UTC