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: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 8 Oct 2014 09:42:13 +0200
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: <F427C068-A5EF-48CF-A4C5-719FD503F8F1@w3.org>
To: Yves Savourel <ysavourel@enlaso.com>
Hi Yves, David, all,

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

>>> We would simply define a rules file with all the rules 
>>> mapping the XLIFF ITS module to ITS.
>>> A pure ITS processor would just use that file.
>> 
>> Wouldn't it be possible to use the rules element at the file level? 
>> to avoid referencing an external rules file? 
> 
> One could do this, but I'm not sure it's very practical:
> 
> a) Any processor that can process global rules must be able to process external files. The rules file will always be the same so there is no point duplicating all over the place. In addition I would expect very few ITS-only processor to process XLIFF files (compared to XLIFF processors)
> 
> b) Having a rules element at the top would somehow implies that the XLIFF processor should be able to process it too. And we said that was not going to be the case. (All ITS markup in local).
> 
> 
>>> Fredrik suggestion has several advantages:
>>> - It decouple ITS and XLIFF namespaces
>> 
>> Not sure if this is an advantage.. 
> 
> 
>>> - We would need only a single namespace for the module 
>>> (doing the job for both the ITS one and the supplemental one)
>> 
>> I think it could be useful to keep them apart to be clear on what a exists 
>> locally in generic ITS and what had to be "made up" for XLIFF puposes. 
>> I guess could be useful for extractor/merger implementers. 
> 
> Actually, let me correct my statement: None of the markup in the module namespace would be ITS anyway (It's really all like a supplemental one) so there is no need for two namespaces.
> 
> 
>>> - It would allow both namespaces to evolve (be updated) separately if needed
>> 
>> I think that this is the only disadvantage of this solution: supporting 
>> the namespaces in two separate locations, under separate authorities, 
>> is error prone and an opportunity for divergence.
> 
> Not if they are versioned.
> 
> Now, the sooner someone start the mapping, the better to catch potential issues with this.

I assume by „start the mapping“ you mean: creating example input and output files? The had designed design of these a while ago in the ITS IG but did not get very far. I put some questions in the ITS IG wiki see
https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Testing_the_mapping
once we have resolved them I’m happy to start with file creation.

Best,

Felix

> 
> Cheers,
> -yves
> 
> 
> 
Received on Wednesday, 8 October 2014 07:42:48 UTC

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