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

Hi David, all,

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

Sure: I don't meant to change everything. I just want:
 a) to make sure we have a normative statement for each data category,
 and b) that the section is very easy to read *per data category*. This is especially true since an implementer may implement only some data categories.


> My thinking is that the ITS module should follow the structure 
> of other modules as far as possible, ...

Sure. But that should come second to having things very clear.
The ITS module is far from being similar to the other: if it requires a somewhat different organization, so be it.


> But simply listing a category in the module does not make the 
> text of the description verifiable in implementations.

Why not? How is it different from any other description in other modules?
We even discussed output test files.
http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Nov/att-0016/translate.xlf.txt


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

I think there is some confusion here: The rule file is not for the XLIFF processors aware of the ITS module, it is for the pure ITS processor wanting to process the XLIFF file.


> XLIFF core agents will not be affected by the fact that the 
> translate attribute is interpreted as the Translate category of ITS.

Not sure why we would talk about core agents.
The module is about agents implementing the ITS module.


> This is strictly speaking only relevant for Extractors/Mergers and 
> ITS Processors who will be using the rules file.

This is where the confusion is: It's not about extractors or ITS processors. It's about XLIFF processors implementing the ITS module. They do not use 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.

The mock-up has an example for the Translate data category. The normative part I think we must would be something like: "It is represented with the [translate] attribute of the Core."

The rules file is for ITS processors, the normative statements for the XLIFF processors (which do not even look at the rules file).

BTW: the rule file is quite advanced in the wiki:
http://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Rules_file_for_the_mapping


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

This is not about layout. It about making sure we have XLIFF normative statements about how each ITS data category is represented (or not).


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

In my opinion we are running out of time for an ITS module that would include all data categories (even without the discussion here). We have not even started to discuss most of them and the holidays are in less than 3 weeks. And we have almost no implementations yet.

Hopefully I'll be wrong, but at some point it looks like we'll have to decide between limiting the module to some data categories for this time around, and postponing 2.1.

Cheers,
-yves

Received on Thursday, 4 December 2014 12:38:17 UTC