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

Re: ITS module section(s) in the specification

From: Dr. David Filip <David.Filip@ul.ie>
Date: Mon, 24 Nov 2014 20:50:47 +0000
Message-ID: <CANw5LKkS_0EK7id4bfu55Vj8_Dp8OGq5Rk7Sv0WAcfztQ8cJ9w@mail.gmail.com>
To: Felix Sasaki <fsasaki@w3.org>
CC: Yves Savourel <ysavourel@enlaso.com>, XLIFF Main List <xliff@lists.oasis-open.org>, "public-i18n-its-ig@w3.org" <public-i18n-its-ig@w3.org>
We need to talk about that in the next meeting..
I have strong reservations to putting everything into the module..

Again, the detailed specification is not done and I am not sure if it makes
logical sense to make the appendix normative. I tend to think not atm..

If you put everything on the module, you're forcing people to go to the
module even if they only want to know what is available w/o the module.

The module specifies everything that needs to be added to XLIFF to be able
to fully support ITS.
Putting other things there is confusing and unclean from the normative
point of view.

The modules indeed ARE about what needs to be added. I don't see why this
one should be different.

the relationship between ITS Translate and XLIFF Transdlate is not as
simple as you suggest.

You yourself specified on the wiki that translate can be implemented as non
extraction or hiding of stuff in codes.

So there is indeed nothing normative about the Translate description in
XLIFF, it is merely a description of ways that are available in XLIFF to
encode the category and what the extractors/mergers do about that is
strictly implementation specific and I cannot see any sensible normative
statements we could make about that.


Dr. David Filip
OASIS XLIFF TC Secretary, Editor, and Liaison Officer
University of Limerick, Ireland
telephone: +353-6120-2781
*cellphone: +353-86-0222-158*
facsimile: +353-6120-2734
mailto: david.filip@ul.ie

On Mon, Nov 24, 2014 at 1:32 PM, Felix Sasaki <fsasaki@w3.org> wrote:

> Am 24.11.2014 um 14:16 schrieb Yves Savourel <ysavourel@enlaso.com>:
> > Hi David, all,
> >
> > (I'm starting a different thread on this topic, to avoid mixing it with
> the Localization-Note one)
> >
> >> I think it is unresolved as yet, if the ITS appendix will
> >> be informative or normative. However, there is very little what
> >> can be normatively stated about XLIFF features as being used to
> >> express ITS features.
> >
> > I'm not sure why we would make non-normative the descriptions of how
> existing XLIFF constructs map to ITS data categories. The ITS module is not
> just about the parts we have to add, it describes all data categories.
> >
> > Having a list of the data categories and for each say how it is
> represented in XLIFF (through existing constructs and/or the itsm
> namespace) seems simple. And in that case having, for example, the
> description for Translate being non-normative while the one for LQI being
> normative seems difficult to justify.
> +1.
> - Felix
> >
> > Why make things complicated? Is translate='yes|no' the only way to
> represent the Translate data category? Yes, so why not stating it
> normatively? In addition one can say that all ITS data categories need to
> be complemented with itsm:annotatorsRef, so none is completely represented
> in the XLIFF core.
> >
> > Cheers,
> > -yves
> >
> >
> >
Received on Monday, 24 November 2014 20:51:54 UTC

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