OASIS XML Localisation Interchange File Format (XLIFF) TC

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

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

HI David, all, Am 03.12.2014 um 22:06 schrieb Dr. David Filip < David.Filip@ul.ie >: 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. Looking at Yves’ mockup, there seem to be many parts that would not be understood by a generic ITS processors, like: „ • The id attribute is REQUIRED.“ (for terminology) „If the annotation has an itsm:termConfidence attribute, it must be within the scope of an itsm:annotatorsRef with the terminology annotator set.“ . Scope here seems to be the unit, not the whole XML file (which it would be for a generic ITS processor). 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. We had discussed to have an ITS IG call on the 8th http://www.w3.org/2014/11/10-i18nits-minutes.html#item09 and to analyze the state of the ITS + XLIFF endeavor and how to move forward. - would that still work for you? I would not mind to discuss this at any of the two TCs. Practically again and of course unfortunately the 16th does not work for me. Best, Felix 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

Thanks Felix, I agree let's discuss on 8th on the IG call, but of course let's keep the discussion available to the TC. Looking at Yves’ mockup, there seem to be many parts that would not be understood by a generic ITS processors, like: „ • The id attribute is REQUIRED.“ (for terminology) „If the annotation has an itsm:termConfidence attribute, it must be within the scope of an itsm:annotatorsRef with the terminology annotator set.“ . Scope here seems to be the unit, not the whole XML file (which it would be for a generic ITS processor). This (and other normative stuff) is (or is going to be)  not only in Yves mock up but also in the current Working Draft. I believe that there is no dissent about the actual technical solution. I think this is just a debate about layout within the 2.1 spec, which is premature IMHO as I keep saying..  I also said that the mockup has a big overlap with the actual working draft..

Am 04.12.2014 um 10:56 schrieb Dr. David Filip < David.Filip@ul.ie >: Thanks Felix, I agree let's discuss on 8th on the IG call, but of course let's keep the discussion available to the TC. Looking at Yves’ mockup, there seem to be many parts that would not be understood by a generic ITS processors, like: „ • The id attribute is REQUIRED.“ (for terminology) „If the annotation has an itsm:termConfidence attribute, it must be within the scope of an itsm:annotatorsRef with the terminology annotator set.“ . Scope here seems to be the unit, not the whole XML file (which it would be for a generic ITS processor). This (and other normative stuff) is (or is going to be)  not only in Yves mock up but also in the current Working Draft. I believe that there is no dissent about the actual technical solution. I think this is just a debate about layout within the 2.1 spec, which is premature IMHO as I keep saying..  Well, then we need more time to make it mature, no? I understand the timing of the XLIFF 2.1 specification. But if the layout of the feature in the spec is premature, then shouldn’t we rather take more time? Best, Felix

Hi Felix, all, > Looking at Yves? mockup, there seem to be many parts > that would not be understood by a generic ITS processors, like: > > ? ? The id attribute is REQUIRED.? (for terminology) > I don't think a generic ITS processor would need to know things like that to work. If it applies the transformation to deal with <sm>/<em> and then applies the rules file, it should have all the info it needs. >> ?If the annotation has an itsm:termConfidence attribute, it must >> be within the scope of an itsm:annotatorsRef with the terminology  >> annotator set.? . > Scope here seems to be the unit, not the whole XML file (which it > would be for a generic ITS processor). I'm not sure I understand the issue. The scope here is the scope of the itsm:annotatorsRef. So that attribute could be set on the element where itsm:termConfidence is on any ancestor where it is allowed. No? Cheers, -yves

Hi Yves, all, Am 04.12.2014 um 13:37 schrieb Yves Savourel <ysavourel@enlaso.com>: > Hi Felix, all, > >> Looking at Yves’ mockup, there seem to be many parts >> that would not be understood by a generic ITS processors, like: >> >> „ • The id attribute is REQUIRED.“ (for terminology) >> > > I don't think a generic ITS processor would need to know things like that to work. If it applies the transformation to deal with > <sm>/<em> and then applies the rules file, it should have all the info it needs. Sure. My point was only that current ITS processors don’t understand that they should apply the transformation. I am just trying to support the point I think you made at http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Dec/0006.html "It about making sure we have XLIFF normative statements about how each ITS data category is represented (or not).“ We want tools processing XLIFF to understand what they need to do. To give a concrete example, Okapi Ocelot is an XLIFF 1.2 editor. It understands also ITS2.0 markup, but you can use it with XLIFF files that don’t have ITS markup at all. If Ocelot is made „ITS module aware“, it will still be an XLIFF editor, implementing the sm / em transformation etc. > > >>> „If the annotation has an itsm:termConfidence attribute, it must >>> be within the scope of an itsm:annotatorsRef with the terminology >>> annotator set.“ . >> Scope here seems to be the unit, not the whole XML file (which it >> would be for a generic ITS processor). > > I'm not sure I understand the issue. > The scope here is the scope of the itsm:annotatorsRef. So that attribute could be set on the element where itsm:termConfidence is on > any ancestor where it is allowed. No? Yes, you are right, that is no issue indeed. Best, Felix > > Cheers, > -yves > > > > >

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