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 <felix@sasakiatcf.com>
Date: Fri, 10 Oct 2014 15:09:15 +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: <C11EDBB1-09B7-48B8-94D2-A5CBC35D72F8@sasakiatcf.com>
To: Yves Savourel <ysavourel@enlaso.com>
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
if we decide against this we can drop this later.



> Any ideas, anyone?
> -yves
Received on Friday, 10 October 2014 13:09:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:05:52 UTC