OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

On Tue, Nov 25, 2014 at 6:11 AM, Felix Sasaki <felix@sasakiatcf.com> wrote:
This sounded to me: you say that in the final specification (os) the appendix should not be normative?

Yes, Felix, I tend to think that all the normative, verifiable stuff should be in the module, i.e. everything that needs to be added to support ITS.

The appendix provides an overview of what is available through core and modules including the itsm module, but does not add itself any normative requirements enforceable with XLIFF implementers.
IMHO we cannot enforce anything with ITS implementers, it would be outside of our chartered scope.

So to cut long story short.. Even if we end up thinking that the Appendix should be reclassified as normative, it will be futile unless there are some testable statements in it.

I am happy to call the appendix normative as soon as it contains a single normative enforceable statement. It just don't see any atm and I personally do not see that it should or could contain any even when finished. But gain I am not dogmatic about that.
If someone comes with some sensible normative statements for the appendix I am happy to have it normative.
Anyways, the conformance clause will be stated in the module.    

Both the the module and the appendix are in the process of making, so I did not understand your previous point and made reference to the publishing/approval process.

We actually still convolute two issue in this thread..

1. Can we make new normative statements about features existing in core and other modules?
I think not. Therefore I tend to think that the appendix should be informative rather than normative.

2. Should all data categories be described in the module?
I think not, I think the module should specify only what needs to be added, to work as any other module so far, albeit bigger.. You go to the module, you see what it specifies and how you support it.

In contrast, all normative statements about XLIFF translate have been made in XLIFF core, the module cannot add new normative requirements for this core feature. If you want to read about the relationship between ITS Translate and XLIFF go read it in the (so far) informative appendix.. Even if the appendix is reclassified as normative it won't be able to make normative statements about the Translate category. There are about three ways how to support it and we since we do not prescribe extraction/merging behavior (only what happens in between) we cannot postulate enforceable requirements. 

For convenience I have no issue with linking the appendix descriptions from the module and linking the module implements from the appendix.
This is in fact what I intend to do as I continue the transfer of the wiki solution onto the spec.

But the split between appendix and module is clear cut IMHO and combining them can only lead to confusion. There already is a place where all categories are described in context and this the W3C Recommendation that we make references to from XLIFF 2.1 both module and appendix..


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]