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

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

xliff message