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

Hi Felix,

> ... I wouldn't see an issue to say: "an ITS 2.0 processor needs to do this X things" 
> then processing XLIFF documents". One thing could be to re-write namespaces, 
> e.g. the namespace of its:annotatorsRef to something which is acceptable for XLIFF2.
> If this would solve the issue (it may not).

It would solve the problem.
We can just add an annotatorsRef attribute as part of the XLIFF Module's namespace.

We just have to be OK with the fact that the file would be temporarily in a 'non-XLIFF' state when being process by an ITS-only
tool.
I suppose that's fine.

-ys


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Felix Sasaki
Sent: Friday, October 10, 2014 7:09 AM
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,

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

> One more note on using a namespace specific to the module:
> 
> It looks like we will have to have the ITS namespace involved because 
> some data category information like mtConfidence or taConfidence MUST have its:annotatorsRef set, and ITS does not provide any
mapping mechanism for that.
> 
> Currently 2.0 defines "XLIFF-defined" constructs are constructs with a 
> namespace starting with "urn:oasis:names:tc:xliff:" (except for pre-2.0 namespaces).
> 
> It also says that XLIFF-defined constructs MUST be preserved and other 
> constructs SHOULD be preserved. So the ITS module's attributes would be preserved for sure, but the accompanying annotatorsRef may
not.
> 
> So, in summary: a tool not supporting the ITS module may break the 
> validity of some features of the ITS module. And do that while being conformant to the processing requirements.
> 
> The solution would be to add "http://www.w3.org/2005/11/its" to the 
> list of namespaces that MUST be preserved. But if we do that we change the expected behavior for the Core and 2.0 tools will have
to be modified to handle 2.1.


It seems more and more there are aspects of processing ITS in XLIFF files that mean: a general ITS 2.0 processor won't do special
handling. So far we have probably mt:confidence (not sure if this can be accommodated in rules) and maybe the handling of milestone
elements (I'll come back to the other thread later). I wouldn't see an issue to say: "an ITS 2.0 processor needs to do this X
things" then processing XLIFF documents". One thing could be to re-write namespaces, e.g. the namespace of its:annotatorsRef to
something which is acceptable for XLIFF2. If this would solve the issue (it may not).

FYI, I added some a link to this thread (potential preprocessing steps) being discussed to
https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#General_implementation_and_testing_considerations
if we decide against this we can drop this later.

Best,

Felix  

> 
> Any ideas, anyone?
> -yves
> 
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Received on Friday, 10 October 2014 14:16:06 UTC