OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi, Please see my comments below marked in blue.   Regards, Rodolfo -- Rodolfo M. Raya Maxprograms http://www.maxprograms.com    

Hi,   Specifically concerning the following points, I agree with Rodolfo completely – I don’t think there can be such a thing as a “specialization of the core”; if so I might fully support XLIFF 2.0 but not specialized XLIFF 2.0 “core” files which doesn’t make sense. If specializations are part of a particular module, as an addition to the core, I can openly state I don’t support it and still be XLIFF 2.0 compliant.   Shirley   Such a module may add additional constructs to the XLIFF document that are fundamental to the data to be translated, not a representation of a process applied to the document. I’m not trying to be pedantic with this question, because I think it's rather important: is a module only something applied to a core, or can it be a specialization of the core for a particular purpose from the beginning?   A module defines elements that are not essential for creating an XLIFF file from common documents. If you are interested on gaming, you can add a request in the wiki for creating a module that defines the elements and attributes that the core lacks. The schema for gaming and the corresponding documentation can be added to XLIFF 2.0 if the TC agrees. This language might imply that the starting point is always a pure-core XLIFF file.   Yes, that's right.   If, however, the module can represent a specialization for something like gaming with requirements that cannot be represented in a core-only format, it has implications for interoperability and they may not be optional at all: you couldn't just ignore the modules in the file and do some processing and the module would go beyond just embedding some tool-specific data in the XLIFF file. So if I create a variable text module like this, have I violated the fundamentals of XLIFF?   It is OK to have modules that create specializations. XLIFF enabled tools will have to support core, support for specializations would be optional.     From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya Sent: November 15, 2011 6:20 PM To: XLIFF TC Subject: RE: [xliff] Definition of "core" and "modules"   Hi, Please see my comments below marked in blue.   Regards, Rodolfo -- Rodolfo M. Raya Maxprograms http://www.maxprograms.com    
Original Message -------- Subject: Re: [xliff] Definition of "core" and "modules" From: Arle Lommel < alommel@gala-global.org > Date: Tue, November 15, 2011 8:44 pm To: Rodolfo M. Raya < rmraya@maxprograms.com > Cc: < xliff@lists.oasis-open.org > Hi all,   I think that Rodolfo's suggestion is a good start with this. It starts to address the problems about imprecision I've mentioned before about the core purpose of XLIFF. Here are few comments: The core of XLIFF 2.0 is the minimum set of XML elements and attributes required to prepare a document that contains text extracted from one or more files “for localization…   My question is if we need to specify the kinds of localization we intend this to cover. For example, if we want to support localization of variable text for games that required mechanisms for including things like gender and number agreement and so forth, the core will have a bunch of things that won't exist if we're more limited. It seems to me that the core should cover items common to many types of localization, while leaving things like gaming, multimedia or other more specialized areas for modules. (But see my question about the intention of modules below.)   We don't specify the kind of localization to do. The core has containers that are enough for the simplest document formats. We offer holders for plain text and basic inline elements. Specialization is out of scope.    As a result I would suggest that the core specify that we are going to support localization of documentation and general software, not everything that might be called localization.   That's OK for me. … can be enhanced with…   Not certain that “enhanced” is the right term. How about “, can be completed with…”?   Fine, "completed" is a better term. …the translation of  the extracted text and allows the generation of translated versions of the original documents.   The namespace that corresponds to the core of XLIFF 2.0 is "urn:oasis:names:tc:xliff:document:2.0". All elements and attributes that belong to the core will be documented in the body of the XLIFF 2.0 specification   Perfect. A module is an optional  set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated to the document as result of that process.    Do modules only store information about a process applied to an XLIFF document ?   No, it also contains data that is added after the XLIFF is created. If you apply TM or MT to an XLIFF file, you will need containers for the matches retrieved by the process.   Let's say that I create a module for variable text for games.   An individual doesn't create a module, the XLIFF TC creates a set of standard modules that support most common cases. One of our goals is to avoid customization that damages interoperability.   Such a module may add additional constructs to the XLIFF document that are fundamental to the data to be translated, not a representation of a process applied to the document. I’m not trying to be pedantic with this question, because I think it's rather important: is a module only something applied to a core, or can it be a specialization of the core for a particular purpose from the beginning?   A module defines elements that are not essential for creating an XLIFF file from common documents. If you are interested on gaming, you can add a request in the wiki for creating a module that defines the elements and attributes that the core lacks. The schema for gaming and the corresponding documentation can be added to XLIFF 2.0 if the TC agrees. This language might imply that the starting point is always a pure-core XLIFF file.   Yes, that's right.   If, however, the module can represent a specialization for something like gaming with requirements that cannot be represented in a core-only format, it has implications for interoperability and they may not be optional at all: you couldn't just ignore the modules in the file and do some processing and the module would go beyond just embedding some tool-specific data in the XLIFF file. So if I create a variable text module like this, have I violated the fundamentals of XLIFF?   It is OK to have modules that create specializations. XLIFF enabled tools will have to support core, support for specializations would be optional. Each module defined for XLIFF 2.0 must have its grammar defined in an independent XML Schema with a separate namespace.   Good. All elements and attributes that belong to a module will be documented in a dedicated annex of the XLIFF 2.0 specification.   Can we change “that belong to a module” to “that belong to officially recognized modules”? We don't want anything that might appear to obligate us to include private modules in an annex to XLIFF 2.0. While I would hope people would document their modules publicly, we cannot make them do so.   There will not be private modules. We agreed some time ago to drop extensibility.   Those companies that created custom extensions had a chance to submit their schemas and documentation for analysis so we can contemplate their needs in XLIFF 2.0. So far we received several schemas but no documentation. It is not easy to consider particular needs when creating a draft schema for XLIFF 2.0 if interested parties don't provide information.   Opinions?   Despite my questions, I think this is an excellent start of something very important. Thank you Rodolfo.   -Arle --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

Hi all, I generally agree with Rodolfo's wording. And see no issue in Arle's text suggestions. Just one note on a side topic that Arle and Rodolfo touched on. (should probably go to a different thread): >> Can we change “that belong to a module” to “that belong >> to officially recognized modules”? We don't want anything >> that might appear to obligate us to include private >> modules in an annex to XLIFF 2.0. While I would hope >> people would document their modules publicly, we cannot >> make them do so. > > There will not be private modules. We agreed some time > ago to drop extensibility. I don't remember any formal vote on the topic of allowing or not extension in 2.0. My understanding has been that it was one possibility, but not a decision. But I may have missed something. > Those companies that created custom extensions had a chance > to submit their schemas and documentation for analysis > so we can contemplate their needs in XLIFF 2.0. So far > we received several schemas but no documentation. It > is not easy to consider particular needs when creating > a draft schema for XLIFF 2.0 if interested parties don't > provide information. I agree, but I'm not sure that justify dropping extensions: We simply cannot think about all features XLIFF may need. The problem is not the extensions. The issue is that some extensions that are used to represent things that already exists in XLIFF, breaking interoperability. I totally agree with requiring that features existing in XLIFF must be use over extensions, always. But if XLIFF does not provide for that feature there is no reason to not allow the extension. I also understand the danger that allowing extension does open the door to abuse. But 2.0 is about also clarifying the specification. This should help a great deal to have tool-makers to be more inclined to avoid extensions when they can. Importantly, we should also set up the same criteria for extension as for the optional modules, like: they should not prevent a tool supporting only the core to work, etc. Cheers, -yves

> I don't remember any formal vote on the topic of allowing or not extension in 2.0. > My understanding has been that it was one possibility, but not a decision. But I may have missed something. If there was a formal decision, it may have happened while I was out of the committee, so I probably missed it as well. > I agree, but I'm not sure that justify dropping extensions: We simply cannot think about all features XLIFF may need. That's the reason for my example about gaming. Right now there is an effort afoot (in ETSI, but independent of the new LIS ISG) to create a standard for representing variable text such as that used in gaming. It would be useful to allow their (eventual) results to be represented in XLIFF format, but they cannot contribute their requirements yet because they don’t know them. The ideal approach would be for them to contribute them as a module in the future, but I'm not sure that such a module would not violate some of our principles if it could not be processed as a core-only document. > The problem is not the extensions. The issue is that some extensions that are used to represent things that already exists in XLIFF, breaking interoperability. They can also be a problem if they add additional functionality that goes beyond core functionality and that keeps the file from being processed. So the issue isn't only about conflict with things that already exist, but also with cases where extensions would be required because processing requirements cannot be handled in a core-only mode without breaking things. > I totally agree with requiring that features existing in XLIFF must be use over extensions, always. Agreed. > But if XLIFF does not provide for that feature there is no reason to not allow the extension. Would it be possible to provide a mechanism for the registration of private extensions? > I also understand the danger that allowing extension does open the door to abuse. There is abuse, as you note, but there are times when companies might want to use XLIFF but find it doesn't quite meet their needs. Forbidding extensions entirely would essentially send the message that XLIFF can only be used in those environments which the committee, in its infinite wisdom, has deemed necessary. But if your use case falls outside of those, you get none of the benefit. I know it's tricky to balance these things, but if we define the modules and disallow extensions, we are simultaneously cutting off some sources of good input. Obviously we don't want to see “XLIFF Wars” like the “Browser Wars” of the 90s with everyone doing things their own ways, but there is a price for cutting off extensions. What if the specification were to contain a stern warning that the XLIFF format does not officially support any third-party extensions, that you can sue them at your own risk, and that they should be used only when existing mechanisms cannot met requirements, along with a request to submit them to the committee for future work? > But 2.0 is about also clarifying the specification. This should help a great deal to have tool-makers to be more inclined to avoid extensions when they can. I think this is true. Given the vagueness of the XLIFF 1.2 specification in many areas, I could see developers using extensions because they don't understand the (undocumented) proper XLIFF way to do things. If 2.0 is clearer and avoids these uncertainties, we would have a specification that would be much easier to implement and much harder to mess up. > Importantly, we should also set up the same criteria for extension as for the optional modules, like: they should not prevent a tool supporting only the core to work, etc. In principle, I agree, but I think there are cases where the data contained may go beyond what XLIFF itself can support. Maybe the solution in that case is to require that anything that would not work with XLIFF core be treated as a filterable payload with XLIFF as the transport mechanism, passing through the markup as metamarkup? That might not be a bad approach anyway since any tool that would want to work with that content would need to be specially enabled anyway, and keeping that support separate from the question of XLIFF. -Arle

Hi Arle, >> Importantly, we should also set up the same criteria >> for extension as for the optional modules, like: >> they should not prevent a tool supporting only >> the core to work, etc. > > In principle, I agree, but I think there are cases > where the data contained may go beyond what XLIFF > itself can support. Not sure if I understand: XLIFF elements "can" support only what they are designed for. Anything else would be extensions. In other words: all use cases of extension should be cases of things the XLIFF specification does not provide for. > Maybe the solution in that case is to require > that anything that would not work with XLIFF core > be treated as a filterable payload with XLIFF > as the transport mechanism, passing through the > markup as metamarkup? Isn't a "filterable payload" the same thing as an extension: something that you add to the XLIFF document, and that XLIFF processors not knowing about it just pass through. I think we need to be strict: If something "would not work with XLIFF core"--which I read: "would prevent an XLIFF tool to work properly"--then it shouldn't be in an XLIFF document. A tool implementing only the core should always be able to do its job regardless what optional modules or extensions are in the document. Cheers, -yves

Hi Yves, Not sure if I understand: XLIFF elements can support only what they are designed for. Anything else would be extensions. In other words: all use cases of extension should be cases of things the XLIFF specification does not provide for. Let me use a more concrete example. That may help make my point clear (or show that I'm completely wrong). Suppose we want a “Variable Text XLIFF”. It might end up looking something like the following (where the module/extension-specific content is in red and I've ignored the need for namespaces):     <?xml version= 1.0 encoding= utf-8 ?>    <xliff version= 2.0 segment= block >       <file srclang= en tgtlang= ru original= variabletext >          <unit id= item1 >              <source>                 <!-- source is something like $1 kill{past} $2 with a sword -->                 <textVariableSet  var_id= A number= sing case= nominative >                    <selector selectorID= 1 gender= masc ><name/></selector>                    <selector selectorID= 2 gender= fem > <name/> </selector>                 </textVariableSet>                  <textVariableSet var_id= B agreesWith= A,C tense= past >                    <!-- The next line tries to show cases where the translation would apply.                         In this case all of them apply since English doesn't care... -->                    <selector selectorID= 3 applicableCases= 1-5,1-6,2-5,2-6 > killed </selector>                 </textVariableSet>                  <textVariableSet  var_id= A number= sing case= accusative >                    <selector selectorID= 5 gender= masc ><name/></selector>                    <selector selectorID= 6 gender= fem > <name/> </selector>                 </textVariableSet>                 with a sword.              </source>              <target>                  <textVariableSet  var_id= A number= sing case= nominative >                    <selector selectorID= 1 gender= masc ><name/></selector>                    <selector selectorID= 2 gender= fem > <name/> </selector>                 </textVariableSet>                  <textVariableSet  var_id= B agreesWith= A,C tense= past >                    <!-- ...but in Russian, it does matter. In a language with complex                         object incorporation you might have four options here! -->                    <selector selectorID= 3 applicableCases= 1-5,1-6 > ???? </selector>                    <selector selectorID= 3 applicableCases= 2-5,2-6 > ????? </selector>                 </textVariableSet>                  <textVariableSet  var_id= A number= sing case= accusative >                    <selector selectorID= 5 gender= masc ><name/></selector>                    <selector selectorID= 6 gender= fem > <name/> </selector>                 </textVariableSet>                 ? ?????.              </target>                        </unit>    </file>    </xliff>   The core stuff is all fine, but if you attempt to translate the <source> element without the tool being aware of the constructs from the module/extension, you will get something wrong. In other words, for the tool to support the translator, it would need to know about the meaning of the module/extension and it could not process it as core only. Processing as core only would result in a bad construct. (And also note that I'm presuming that this stuff relates to a hypothetical variable text standard so it is not a tool-specific thing.) So this is localization-related stuff that the core XLIFF specification does not provide for (and should not provide for, in my opinion), and would be an extension, but such an extension violates the idea that a core-only tool should be able to process it. So maybe the answer is that this format would be treated like IDML, Word, or any other file format that is filtered and the markup stashed inside the appropriate metamarkup elements, despite the clear localization orientation in this case. It would be left up to the tool/user to figure out what to do with the markup, and would not be an XLIFF question at all. I use this example because, at first blush, adding some information about variable text localization would seem like a good candidate for extension (and I think it might have been done like that in 1.2), but it looks like it would end up creating more problems than it's worth. So if the guidance is, as Rodolfo suggested, that information in a module/extension cannot interfere with processing in a core-only mode for 2.0, then this extension would be disallowed and one would be forced to treat the red stuff as native file-format code to be filtered. If that's the answer, I'm fine with that. I simply wanted to understand how far one could go with extension/modules. The answer then is, not really very far, which is a fair answer. -Arle

Hi Arle,   In XLIFF 1.2 you are not able to use custom extensions inside <source> or <target>. These two elements must be supported by any tool that works with XLIFF files and introducing proprietary parts in them would have been a major interoperability disaster.   Not supporting custom extensions in the middle of translatable text is a basic principle that we should maintain.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Arle Lommel Sent: Thursday, November 17, 2011 5:30 PM To: Yves Savourel Cc: 'XLIFF TC' Subject: Re: [xliff] To extend or not to extend. Was: [xliff] Definition of "core" and "modules"   Hi Yves, Not sure if I understand: XLIFF elements "can" support only what they are designed for. Anything else would be extensions. In other words: all use cases of extension should be cases of things the XLIFF specification does not provide for.   Let me use a more concrete example. That may help make my point clear (or show that I'm completely wrong). Suppose we want a “Variable Text XLIFF”. It might end up looking something like the following (where the module/extension-specific content is in red and I've ignored the need for namespaces):       <?xml version="1.0" encoding="utf-8"?>    <xliff version="2.0" segment="block">       <file srclang="en" tgtlang="ru" original="variabletext">          <unit id="item1">              <source>                 <!-- source is something like "$1 kill{past} $2 with a sword" -->                 <textVariableSet  var_id="A" number="sing" case="nominative">                    <selector selectorID="1" gender="masc"><name/></selector>                    <selector selectorID="2" gender="fem"><name/></selector>                 </textVariableSet>                  <textVariableSet var_id="B" agreesWith="A,C" tense="past">                    <!-- The next line tries to show cases where the translation would apply.                         In this case all of them apply since English doesn't care... -->                    <selector selectorID="3" applicableCases="1-5,1-6,2-5,2-6"> killed </selector>                 </textVariableSet>                  <textVariableSet  var_id="A" number="sing" case="accusative">                    <selector selectorID="5" gender="masc"><name/></selector>                    <selector selectorID="6" gender="fem"><name/></selector>                 </textVariableSet>                 with a sword.              </source>              <target>                  <textVariableSet  var_id="A" number="sing" case="nominative">                    <selector selectorID="1" gender="masc"><name/></selector>                    <selector selectorID="2" gender="fem"><name/></selector>                 </textVariableSet>                  <textVariableSet  var_id="B" agreesWith="A,C" tense="past">                    <!-- ...but in Russian, it does matter. In a language with complex                         object incorporation you might have four options here! -->                    <selector selectorID="3" applicableCases="1-5,1-6"> ???? </selector>                    <selector selectorID="3" applicableCases="2-5,2-6"> ????? </selector>                 </textVariableSet>                  <textVariableSet  var_id="A" number="sing" case="accusative">                    <selector selectorID="5" gender="masc"><name/></selector>                    <selector selectorID="6" gender="fem"><name/></selector>                 </textVariableSet>                 ?   ????? .              </target>                        </unit>    </file>    </xliff>   The core stuff is all fine, but if you attempt to translate the <source> element without the tool being aware of the constructs from the module/extension, you will get something wrong. In other words, for the tool to support the translator, it would need to know about the meaning of the module/extension and it could not process it as core only. Processing as core only would result in a bad construct. (And also note that I'm presuming that this stuff relates to a hypothetical variable text standard so it is not a tool-specific thing.)   So this is localization-related stuff that the core XLIFF specification does not provide for (and should not provide for, in my opinion), and would be an extension, but such an extension violates the idea that a core-only tool should be able to process it.   So maybe the answer is that this format would be treated like IDML, Word, or any other file format that is filtered and the markup stashed inside the appropriate metamarkup elements, despite the clear localization orientation in this case. It would be left up to the tool/user to figure out what to do with the markup, and would not be an XLIFF question at all.   I use this example because, at first blush, adding some information about variable text localization would seem like a good candidate for extension (and I think it might have been done like that in 1.2), but it looks like it would end up creating more problems than it's worth. So if the guidance is, as Rodolfo suggested, that information in a module/extension cannot interfere with processing in a core-only mode for 2.0, then this extension would be disallowed and one would be forced to treat the red stuff as native file-format code to be filtered.   If that's the answer, I'm fine with that. I simply wanted to understand how far one could go with extension/modules. The answer then is, not really very far, which is a fair answer.   -Arle

Hi Arle,   Thanks for the example. It’s a good illustration of something that, I think, should not be allowed in 2.0 (just like it is not allowed in 1.2).   You are correct: the extra markup in <source> prevents the core to work. So it shouldn’t be done. Like Rodolfo noted: it is a basic principal that we should maintain.   If people want to have complex modules that do work in XLIFF (in <source> or elsewhere) they should be in the TC right now so their requirements can be taken into account.   But there is another solution: technically all that can likely be represented with one or few extension attributes in a <ph> element of XLIFF and possibly a structure outside <source>. And that whole thing could then be an extension that would not prevent the core to be processed normally.   Maybe it wouldn’t be pretty or elegant, but it would keep interoperability alive.   I think there is nothing wrong for a specific vertical to come up with additional features for XLIFF, as long as they can be treated like an optional module and follow the requirements for that. For example:   -    Cannot break the core -    Cannot represent features that are available in either the core or one of the official optional module. -    Maybe other things…   And, obviously, if anyone would like to see their module be part of the standard ones, I would encourage them to join the TC and work with us on that.   Cheers, -yves     From: Arle Lommel [mailto:alommel@gala-global.org] Sent: Thursday, November 17, 2011 12:30 PM To: Yves Savourel Cc: 'XLIFF TC' Subject: Re: [xliff] To extend or not to extend. Was: [xliff] Definition of "core" and "modules"   Hi Yves, Not sure if I understand: XLIFF elements "can" support only what they are designed for. Anything else would be extensions. In other words: all use cases of extension should be cases of things the XLIFF specification does not provide for.   Let me use a more concrete example. That may help make my point clear (or show that I'm completely wrong). Suppose we want a “Variable Text XLIFF”. It might end up looking something like the following (where the module/extension-specific content is in red and I've ignored the need for namespaces):       <?xml version="1.0" encoding="utf-8"?>    <xliff version="2.0" segment="block">       <file srclang="en" tgtlang="ru" original="variabletext">          <unit id="item1">              <source>                 <!-- source is something like "$1 kill{past} $2 with a sword" -->                 <textVariableSet  var_id="A" number="sing" case="nominative">                    <selector selectorID="1" gender="masc"><name/></selector>                    <selector selectorID="2" gender="fem"><name/></selector>                 </textVariableSet>                  <textVariableSet var_id="B" agreesWith="A,C" tense="past">                    <!-- The next line tries to show cases where the translation would apply.                         In this case all of them apply since English doesn't care... -->                    <selector selectorID="3" applicableCases="1-5,1-6,2-5,2-6"> killed </selector>                 </textVariableSet>                  <textVariableSet  var_id="A" number="sing" case="accusative">                    <selector selectorID="5" gender="masc"><name/></selector>                    <selector selectorID="6" gender="fem"><name/></selector>                 </textVariableSet>                 with a sword.              </source>              <target>                  <textVariableSet  var_id="A" number="sing" case="nominative">                    <selector selectorID="1" gender="masc"><name/></selector>                    <selector selectorID="2" gender="fem"><name/></selector>                 </textVariableSet>                  <textVariableSet  var_id="B" agreesWith="A,C" tense="past">                    <!-- ...but in Russian, it does matter. In a language with complex                         object incorporation you might have four options here! -->                    <selector selectorID="3" applicableCases="1-5,1-6"> ???? </selector>                    <selector selectorID="3" applicableCases="2-5,2-6"> ????? </selector>                 </textVariableSet>                  <textVariableSet  var_id="A" number="sing" case="accusative">                    <selector selectorID="5" gender="masc"><name/></selector>                    <selector selectorID="6" gender="fem"><name/></selector>                 </textVariableSet>                 ?   ????? .              </target>                        </unit>    </file>    </xliff>   The core stuff is all fine, but if you attempt to translate the <source> element without the tool being aware of the constructs from the module/extension, you will get something wrong. In other words, for the tool to support the translator, it would need to know about the meaning of the module/extension and it could not process it as core only. Processing as core only would result in a bad construct. (And also note that I'm presuming that this stuff relates to a hypothetical variable text standard so it is not a tool-specific thing.)   So this is localization-related stuff that the core XLIFF specification does not provide for (and should not provide for, in my opinion), and would be an extension, but such an extension violates the idea that a core-only tool should be able to process it.   So maybe the answer is that this format would be treated like IDML, Word, or any other file format that is filtered and the markup stashed inside the appropriate metamarkup elements, despite the clear localization orientation in this case. It would be left up to the tool/user to figure out what to do with the markup, and would not be an XLIFF question at all.   I use this example because, at first blush, adding some information about variable text localization would seem like a good candidate for extension (and I think it might have been done like that in 1.2), but it looks like it would end up creating more problems than it's worth. So if the guidance is, as Rodolfo suggested, that information in a module/extension cannot interfere with processing in a core-only mode for 2.0, then this extension would be disallowed and one would be forced to treat the red stuff as native file-format code to be filtered.   If that's the answer, I'm fine with that. I simply wanted to understand how far one could go with extension/modules. The answer then is, not really very far, which is a fair answer.   -Arle

I think we're all in agreement then. Your mention of using <ph> is what I had in mind by saying that this made-up format would be treated just like IDML, Word, etc. I could see cases where other stuff could be added in <source> that wouldn't create a problem, but this is clear example of where it would definitely cause a problem. I think your principles (and a discussion I just had with Rodolfo) address this issue to my satisfaction (meaning I am now clear on the principle, not that anyone had to change anything). -Arle On Nov 17, 2011, at 11:22 , Yves Savourel wrote: Hi Arle,   Thanks for the example. It’s a good illustration of something that, I think, should not be allowed in 2.0 (just like it is not allowed in 1.2).   You are correct: the extra markup in <source> prevents the core to work. So it shouldn’t be done. Like Rodolfo noted: it is a basic principal that we should maintain.   If people want to have complex modules that do work in XLIFF (in <source> or elsewhere) they should be in the TC right now so their requirements can be taken into account.   But there is another solution: technically all that can likely be represented with one or few extension attributes in a <ph> element of XLIFF and possibly a structure outside <source>. And that whole thing could then be an extension that would not prevent the core to be processed normally.   Maybe it wouldn’t be pretty or elegant, but it would keep interoperability alive.   I think there is nothing wrong for a specific vertical to come up with additional features for XLIFF, as long as they can be treated like an optional module and follow the requirements for that. For example:   -      Cannot break the core -      Cannot represent features that are available in either the core or one of the official optional module. -      Maybe other things…   And, obviously, if anyone would like to see their module be part of the standard ones, I would encourage them to join the TC and work with us on that.   Cheers, -yves  

> I think we're all in agreement then. Your mention of using > <ph> is what I had in mind by saying that this made- > up format would be treated just like IDML, Word, etc. Actually I meant to say that *instead* of using the elements in your example, they could probably have a different set of elements/attributes that would work in the XLIFF core. So there would be no need for additional filtering, etc. The following is such an example. Here it make probably no sense because I don't know what those elements means, but the idea is that you can likely adapt your data model to XLIFF. <unit id="item1"> <source><ph id='1' gx:ref='A'>$1</ph> kill<ph id='2' gx:ref='B'>{past}</ph> <ph id='3' gx:ref='C'>$2</ph> with a sword</source> ... <gx:varTextParams> <gx:textVariableSet var_id="A" number="sing" case="nominative"> <gx:selector selectorID="1" gender="masc"><gx:name/></gx:selector> <gx:selector selectorID="2" gender="fem"><gx:name/></gx:selector> </gx:textVariableSet> ...etc. </gx:varTextParams> </unit> And that would be better than go to some proprietary format first, and then go to XLIFF from that proprietary format. The fewer intermediary steps the better. By the way we do have a feature in the "proposed" category that deals with representation of plural. That may be related to your example. ( http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Plural%20Entries ) Cheers, -ys

That's an interesting approach, and shows how something like this could be made to work in XLIFF. Rodolfo provided another way to me earlier in a conversation that is even more XLIFF-like in its output (it involved “exploding” the selectors to create a full set of all the possibilities that could be easily translated in XLIFF) and would put the difficulty of dealing with the strange variable notation into the filter and produce clean and clear XLIFF. So there are ways to deal with it and which would be better probably depends on a lot of factors. But this was all an example to get at a principle that I think is now resolved. Best, -Arle On Nov 17, 2011, at 12:19 , Yves Savourel wrote: >> I think we're all in agreement then. Your mention of using >> <ph> is what I had in mind by saying that this made- >> up format would be treated just like IDML, Word, etc. > > Actually I meant to say that *instead* of using the elements in your example, they could probably have a different set of elements/attributes that would work in the XLIFF core. So there would be no need for additional filtering, etc. > > The following is such an example. Here it make probably no sense because I don't know what those elements means, but the idea is that you can likely adapt your data model to XLIFF. > > <unit id="item1"> > <source><ph id='1' gx:ref='A'>$1</ph> kill<ph id='2' gx:ref='B'>{past}</ph> <ph id='3' gx:ref='C'>$2</ph> with a sword</source> > ... > <gx:varTextParams> > <gx:textVariableSet var_id="A" number="sing" case="nominative"> > <gx:selector selectorID="1" gender="masc"><gx:name/></gx:selector> > <gx:selector selectorID="2" gender="fem"><gx:name/></gx:selector> > </gx:textVariableSet> > ...etc. > </gx:varTextParams> > </unit> > > And that would be better than go to some proprietary format first, and then go to XLIFF from that proprietary format. The fewer intermediary steps the better. > > By the way we do have a feature in the "proposed" category that deals with representation of plural. That may be related to your example. ( http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Plural%20Entries ) > > Cheers, > -ys > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xliff-help@lists.oasis-open.org >