OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC

  • 1.  Content of source/target

    Posted 04-30-2017 21:56
    Hi all,   Looking at https://github.com/oasis-tcs/xliff-omos-jliff/blob/master/JLIFF-schema-draft/jliff-example3-0.9.3.json   We have:   "source": [ { "text": "Quetzal" } ]   But shouldn’t that be the content set as a separate object in “source”? Something like:   "source": {   "cnt": [     {       "text": "Quetzal"     }   ] }   The reason being that both source and target can have an xml:lang and/or an xml:space field in addition to their content. Even if we decide that the xml:space field applies always to both and could be set on the parent sub-unit, we cannot do this for xml:lang, which is mostly set with different values. Or we would have to carry two sub-unit-level fields instead (e.g. srcLang and trgLang), which may be better. But even in that case, target has also an order field in addition to its content. I suppose that field could be also carried at the sub-unit level.   Cheers.     Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  


  • 2.  RE: [xliff-omos] Content of source/target

    Posted 04-30-2017 23:58
    After more tests, it definitely seems it would make implementations a lot easier to move the four fields: source-language, target-language, preserve-white-space, and target-order which are distributed in <source> and <target> in XLIFF to the segment/ignorable (sub-unit) in the object model:   ·        This would allow source and target to use the same interface and implementation. ·        That would not prevent the XLIFF output ·        The JLIFF source and target objects could be just an array of text/tags like in the current example, without any other fields.   Thoughts?     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Sunday, April 30, 2017 3:56 PM To: 'XLIFF OMOS TC' <xliff-omos@lists.oasis-open.org> Subject: [xliff-omos] Content of source/target   Hi all,   Looking at https://github.com/oasis-tcs/xliff-omos-jliff/blob/master/JLIFF-schema-draft/jliff-example3-0.9.3.json   We have:   "source": [ { "text": "Quetzal" } ]   But shouldn’t that be the content set as a separate object in “source”? Something like:   "source": {   "cnt": [     {       "text": "Quetzal"     }   ] }   The reason being that both source and target can have an xml:lang and/or an xml:space field in addition to their content. Even if we decide that the xml:space field applies always to both and could be set on the parent sub-unit, we cannot do this for xml:lang, which is mostly set with different values. Or we would have to carry two sub-unit-level fields instead (e.g. srcLang and trgLang), which may be better. But even in that case, target has also an order field in addition to its content. I suppose that field could be also carried at the sub-unit level.   Cheers.     Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  


  • 3.  Re: [xliff-omos] Content of source/target

    Posted 05-08-2017 22:28
    Hi Yves, +1 for this suggested approach.  I wanted to make a few comments about the individual fields. For whitespace preservation, I would like to see if we can get away with just specifying that JLIFF always preserves whitespace.  The xml:space behavior is an XML-ism that causes, in my experience, a certain amount of incompatibility due to implementation error.  Is there a downside to this? The order attribute is difficult to work with in its current form.  A more intuitive way to represent that use case might be an explicit mapping from sources to targets, but this would require a pretty big shake-up to the unit structure, and the use case is obscure. For source/target language, this goes back to our discussion on during the March 28 call regarding inheritance.  During that call David was expressing concern about the possibility of multiple source/target languages being expressed in a single unit, and was trying to think through the markup needed to prevent that. I've always found this part of the XLIFF 2.0 spec weird, because although the format is clearly intended to be bilingual (Section 4: "XLIFF is a bilingual document format"), there is no language I'm aware of in the spec that prevents individual <target> elements inside a single <unit> from having different xml:lang values.  (This constraint does exist on the description of the <source> and <target> elements in the resource module in section 5, but not on the core elements!) So if we need to preserve that flexibility, then I think we're trapped with putting it in the subunit as you suggest.  If there is some way we can get away with saying that within a single unit there can be only one language pair, we would have other options, but I'm not sure that's possible while maintaining XLIFF compatibility. On Sun, Apr 30, 2017 at 4:57 PM, Yves Savourel < ysavourel@enlaso.com > wrote: After more tests, it definitely seems it would make implementations a lot easier to move the four fields: source-language, target-language, preserve-white-space, and target-order which are distributed in <source> and <target> in XLIFF to the segment/ignorable (sub-unit) in the object model:   ·        This would allow source and target to use the same interface and implementation. ·        That would not prevent the XLIFF output ·        The JLIFF source and target objects could be just an array of text/tags like in the current example, without any other fields.   Thoughts?     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: xliff-omos@lists.oasis-open. org [mailto: xliff-omos@lists. oasis-open.org ] On Behalf Of Yves Savourel Sent: Sunday, April 30, 2017 3:56 PM To: 'XLIFF OMOS TC' < xliff-omos@lists.oasis-open. org > Subject: [xliff-omos] Content of source/target   Hi all,   Looking at https://github.com/oasis-tcs/ xliff-omos-jliff/blob/master/ JLIFF-schema-draft/jliff- example3-0.9.3.json   We have:   "source": [ { "text": "Quetzal" } ]   But shouldn’t that be the content set as a separate object in “source”? Something like:   "source": {   "cnt": [     {       "text": "Quetzal"     }   ] }   The reason being that both source and target can have an xml:lang and/or an xml:space field in addition to their content. Even if we decide that the xml:space field applies always to both and could be set on the parent sub-unit, we cannot do this for xml:lang, which is mostly set with different values. Or we would have to carry two sub-unit-level fields instead (e.g. srcLang and trgLang), which may be better. But even in that case, target has also an order field in addition to its content. I suppose that field could be also carried at the sub-unit level.   Cheers.     Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  


  • 4.  RE: [xliff-omos] Content of source/target

    Posted 05-09-2017 12:35
    Hi all,   One comment on the source/target language:   Ø   For source/target language, this goes back to our discussion on during the March 28 call regarding inheritance.  During that call David was expressing concern about the possibility of multiple source/target languages being expressed in a single unit, and was trying to think through the markup needed to prevent that. Ø   I've always found this part of the XLIFF 2.0 spec weird, because although the format is clearly intended to be bilingual (Section 4: "XLIFF is a bilingual document format"), there is no language I'm aware of in the spec that prevents individual <target> elements inside a single <unit> from having different xml:lang values.  (This constraint does exist on the description of the <source> and <target> elements in the resource module in section 5, but not on the core elements!)   I believe the allowance is there for the matches, where <source> and <target> could be in languages different from the document’s source and target. For example, offering French Canadian matches when translating into French, or Simplified Chinese when going to Traditional, etc.   So any different xml;lang case should be occurring only in the Translation Candidates module. I’m not sure this was a great choice to re-use the core <source> and <target> in that module, but that is what we have now.   I think the <source> and <target> element in the resources module are in a different namespace.   Cheers, -yves