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

Thanks, Yves, more inline..

This would allow only ITS processor that support external rules to work
> with the file. (But it's already the case for the data categories using the
> supplemental its-xliff namespace anyway).
>
> 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?

>
> The XLIFF processors implementing the ITS module would not need to use it.
>
> 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.

> - 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..

>
> Neither OASIS nor the W3C have to agree with anything here: it's just the
> XLIFF TC creating a new module and using ITS the way it's used for many
> other formats: through mapping.
>

I like that aspect, i.e. that in this case everything is clearly in OASIS
XLIFF TC jurisdiction

Cheers
dF

>
>
> Cheers,
> -yves
>
>
>
>
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On
> Behalf Of Dr. David Filip
> Sent: Tuesday, October 7, 2014 12:15 PM
> To: xliff@lists.oasis-open.org
> Subject: [xliff] possible issue with URN prefixes used to define
> acceptable namespaces in XLIFF 2.1
>
> Hi all,
>
> I started working on preparing the working draft for incorporation of the
> newly approved features.
>
> This is issue might be relevant for both ITS support and advanced
> validation.
>
> In order to support many ITS categories as XLIFF defined modules we will
> need to include the ITS namespace among XLIFF defined namespaces.
>
> We did that using URN prefixes in XLIFF 2.0, which is not an issue for
> OASIS namespaces as OASIS does maintain a persistent URN structure.
> However w3c apparently stopped caring for URNs back in 2005 or even
> earlier.
>
> Now how do we go about accepting these two namespaces:
> ITS 2.0 namespace
> http://www.w3.org/2005/11/its/
> ITS-XLIFF namespace
> http://www.w3.org/ns/its-xliff/
>
> In the XLIFF TC teleconference, Fredrik and Yves, suggested that we define
> 1 or 2 OASIS namespaces, XLIFF module namespaces similar to this one:
> • urn:oasis:names:tc:xliff:resourcedata:2.0
> that will include the subset of the ITS attributes and maybe also elements
> actually used..
>
> I am not opposed to that as it would allow us to stick to the URN prefix
> convention that we use in XLIFF 2.0
> • urn:oasis:names:tc:xliff:its:2.1
> • urn:oasis:names:tc:xliff:itsxlf:2.1
>
> Fredrik, Yves, would you care to explain how would this work (if at all)
> with generic ITS processors that would expect the original w3c namespace?
> Would we need to include a mapping rule in the XLIFF root?
>
> I hope that we can agree how the solution would work technically so that
> we can propose the solution to the W3C ITS IG and discuss if this is
> acceptable from the W3C point of view.
>
> Thanks and regards
> dF
>
>
>
>
> Dr. David Filip
> =======================
> OASIS XLIFF TC Secretary, Editor, and Liaison Officer
> LRC | CNGL | CSIS
> University of Limerick, Ireland
> telephone: +353-6120-2781
> cellphone: +353-86-0222-158
> facsimile: +353-6120-2734
> http://www.cngl.ie/profile/?i=452
> mailto: david.filip@ul.ie
>
>