Re: [xliff] ITS module section(s) in the specification

Yves, sorry, I missed the actual mock up in the cited message..
I followed the link to the wiki and thought that it was it..

Your mock up partially overlaps with what already is in the module. Like
the namespace declaration, and prefix etc.

My thinking is that the ITS module should follow the structure of other
modules as far as possible, there will be of course extra parts, like the
external rules file for generic ITS processors. It is also fine to have a
longer introduction as this module covering so many categories needs some
sort of foreword.
Of course also the Annotators reference needs covered, so I will implement
that right away.

I understand that you want to cover all categories in the module.
But simply listing a category in the module does not make the text of the
description verifiable in implementations.
On the other hand, all categories, even the ones (2) fully expressed with
core will be affected by the rules file.
So I think once the rules file is ready for inclusion, we can list the
categories that are normatively covered only by the rules file.
It should be Translate and Localization Note, but maybe also Preserve Space
and Language Information, if we decide to break out these two into a small
separate module.
XLIFF core agents will not be affected by the fact that the translate
attribute is interpreted as the Translate category of ITS. This is strictly
speaking only relevant for Extractors/Mergers and ITS Processors who will
be using the rules file.
So I still do not see what else should be normatively said about the
Translate and Note data categories except that ITS Processors MUST map them
onto the respective data categories using the rules file that has not been
developed yet.

Again I think it is too early to push certain layout of categories when the
technical solution has not yet been fully transferred from the wiki to the
spec.
I am doing my best to finish this task by Xmas or hopefully by the meeting
on 16th.
I think that we can continue arguing about the reshuffle or not when the
technical solution has been fully developed and transferred to the spec.
I consider the current working drat layout provisional and happy to fine
tune it when it becomes reasonably feature complete.
I plan to use your mock up and the wiki to check if we're missing any type
of relevant normative info and of course all the normative info will need
to go to the module.

Cheers
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

On Mon, Nov 24, 2014 at 1:16 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

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