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

Expand all | Collapse all

Source and Target Language properties for Fragment

  • 1.  Source and Target Language properties for Fragment

    Posted 03-06-2017 14:08
    I think it would be good for fragment to have source and target language properties so they can be set once for the whole fragment.   Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global


  • 2.  RE: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-06-2017 16:08
    Hi, Two comments: 1) "Fragment": It’s probably a bit late to react to this, but I had no time before to really follow the discussion. The term “fragment” which, looking at https://github.com/oasis-tcs/xliff-omos-jliff/blob/master/JLIFF-schema-draft/jliff-schema-0.9.3.json designates the XLIFF <file>, seems very misleading to me. For me (and maybe it’s just me) a fragment is something small, one of the low-level objects of a model. If we don't want to keep the term "file" (although existing object models like Okapi's and Microsoft's Oms use it) maybe something like "resource" or "set" or something of that effect would be better. 2) source/target > I think it would be good for fragment to have source and target > language properties so they can be set once for the whole fragment. Just to be sure we are on the same page: We all are in agreement that there is no 'inheritance' in JLIFF, right? So setting them at the top-level object would means setting the values the same in the units as well. Cheers, -yves From: xliff-omos@lists.oasis-open.org [ mailto:xliff-omos@lists.oasis-open.org ] On Behalf Of Phil Ritchie Sent: Monday, March 6, 2017 7:07 AM To: xliff-omos@lists.oasis-open.org Subject: [xliff-omos] Source and Target Language properties for Fragment I think it would be good for fragment to have source and target language properties so they can be set once for the whole fragment. Phil Ritchie Chief Technology Officer Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel: +353 1 416 8000 Direct: +353 1 416 8024 Email: phil.ritchie@vistatec.com www.vistatec.com ISO 9001 ISO 13485 ISO 17100 Think Global


  • 3.  RE: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-06-2017 17:05
    With regard to "fragment" I agree with Yves' proposition that I would normally understand it to be something small and a constituent of something bigger. "resource" would also have other connotations. How about "section" or "subset"? Can we not introduce the concept of inheritance? > Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global


  • 4.  Re: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-08-2017 15:06
    Phil, since Robert can enforce defaults with his schema, I guess we could construe inheritance if we cared enough, but I don't think that our goal is to make JSON behave as XML, we just want to instantiate the properties necessary at the fragment exchange level, necessary not to break a process that switches between the XML and JSON pipelines.. If our goal was to recreate full XLIFF in JSON then we probably would have to force JSON to inherit, but we agreed that this was not our goal ;-) Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Mar 6, 2017 at 5:05 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: With regard to "fragment" I agree with Yves' proposition that I would normally understand it to be something small and a constituent of something bigger. "resource" would also have other connotations. How about "section" or "subset"? Can we not introduce the concept of inheritance? > Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global


  • 5.  Re: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-08-2017 15:36
    Sorry but as a side note I do not know what it is that makes inheritance a characteristic of XML and not of Json. I thought it was something employed/bestowed by the applications rather than something inherent in the format/technology. They both are graphs so I assumed hierarchy and inheritance were by-products. Anyway, I am most interested in the practical use and size/repetition minimisation. Having the languages at the highest level just reduces both. Phil Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global On 8 Mar 2017, at 15:05, David Filip < david.filip@adaptcentre.ie > wrote: Phil, since Robert can enforce defaults with his schema, I guess we could construe inheritance if we cared enough, but I don't think that our goal is to make JSON behave as XML, we just want to instantiate the properties necessary at the fragment exchange level, necessary not to break a process that switches between the XML and JSON pipelines.. If our goal was to recreate full XLIFF in JSON then we probably would have to force JSON to inherit, but we agreed that this was not our goal ;-) Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Mar 6, 2017 at 5:05 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: With regard to "fragment" I agree with Yves' proposition that I would normally understand it to be something small and a constituent of something bigger. "resource" would also have other connotations. How about "section" or "subset"? Can we not introduce the concept of inheritance? > Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global


  • 6.  Re: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-08-2017 15:58
    Phil, I don't want to go into the philosophical debate if inheritance is XML specific (I guess not, you can do it fairly easily on any tree graphs).. Suffice it to say that JSON is not well suited for inheritance and hence I would suggest to have the (one) language property at the source and target level (which will automatically differentiate them as source and target languages). Maybe the repetition level will be theoretically higher, but in many cases you will be exchanging fragments with just one source and target. And -more importantly- you won't need to go into the extra trouble of defining source and target language (two different) properties at the unit level and make them inherit to source and target conditionally.. I guess should be also simpler for implementers/ serializers/ deserializers Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Wed, Mar 8, 2017 at 3:36 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: Sorry but as a side note I do not know what it is that makes inheritance a characteristic of XML and not of Json. I thought it was something employed/bestowed by the applications rather than something inherent in the format/technology. They both are graphs so I assumed hierarchy and inheritance were by-products. Anyway, I am most interested in the practical use and size/repetition minimisation. Having the languages at the highest level just reduces both. Phil Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global On 8 Mar 2017, at 15:05, David Filip < david.filip@adaptcentre.ie > wrote: Phil, since Robert can enforce defaults with his schema, I guess we could construe inheritance if we cared enough, but I don't think that our goal is to make JSON behave as XML, we just want to instantiate the properties necessary at the fragment exchange level, necessary not to break a process that switches between the XML and JSON pipelines.. If our goal was to recreate full XLIFF in JSON then we probably would have to force JSON to inherit, but we agreed that this was not our goal ;-) Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Mar 6, 2017 at 5:05 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: With regard to "fragment" I agree with Yves' proposition that I would normally understand it to be something small and a constituent of something bigger. "resource" would also have other connotations. How about "section" or "subset"? Can we not introduce the concept of inheritance? > Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circ ular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global


  • 7.  RE: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-08-2017 16:12
    To make clear, can you post a json sample?     Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global From: David Filip [mailto:david.filip@adaptcentre.ie] Sent: 08 March 2017 15:57 To: Phil Ritchie <phil.ritchie@vistatec.com> Cc: Yves Savourel <ysavourel@enlaso.com>; xliff-omos@lists.oasis-open.org Subject: Re: [xliff-omos] Source and Target Language properties for Fragment   Phil, I don't want to go into the philosophical debate if inheritance is XML specific (I guess not, you can do it fairly easily on any tree graphs).. Suffice it to say that JSON is not well suited for inheritance and hence I would suggest to have the (one) language property at the source and target level (which will automatically differentiate them as source and target languages). Maybe the repetition level will be theoretically higher, but in many cases you will be exchanging fragments with just one source and target. And -more importantly- you won't need to go into the extra trouble of defining source and target language (two different) properties at the unit level and make them inherit to source and target conditionally.. I guess should be also simpler for implementers/ serializers/ deserializers   Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Wed, Mar 8, 2017 at 3:36 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   Sorry but as a side note I do not know what it is that makes inheritance a characteristic of XML and not of Json. I thought it was something employed/bestowed by the applications rather than something inherent in the format/technology. They both are graphs so I assumed hierarchy and inheritance were by-products.   Anyway, I am most interested in the practical use and size/repetition minimisation. Having the languages at the highest level just reduces both. Phil       Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global     On 8 Mar 2017, at 15:05, David Filip < david.filip@adaptcentre.ie > wrote: Phil,   since Robert can enforce defaults with his schema, I guess we could construe inheritance if we cared enough, but I don't think that our goal is to make JSON behave as XML, we just want to instantiate the properties necessary at the fragment exchange level, necessary not to break a process that switches between the XML and JSON pipelines..   If our goal was to recreate full XLIFF in JSON then we probably would have to force JSON to inherit, but we agreed that this was not our goal ;-)   Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Mon, Mar 6, 2017 at 5:05 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   With regard to "fragment" I agree with Yves' proposition that I would normally understand it to be something small and a constituent of something bigger. "resource" would also have other connotations. How about "section" or "subset"? Can we not introduce the concept of inheritance? >   Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global  


  • 8.  Re: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-09-2017 13:12
    Phil, taking a fragment from this Example on the jliff repo https://github.com/oasis-tcs/xliff-omos-jliff/blob/master/JLIFF-schema-draft/jliff-example1-0.9.3.json   [I removed the line that represented pc as a pair tag, as we want to represent that linearly with empty tags and that is not the point here] " subunit " : [ { " type " : " segment " , " state " : " translated " , " canResegment " : false , " source " : [{ " lang " : " EN " }], [ { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " }, { " text " : " messages " } ], " target " : [{ " lang " : " CS " }], [ { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " }, { " text " : " zpráv " } ] }, { " type " : " ignorable " , " source " : [ { " text " : " . " } ] If the brackets don't add up after my edit, I hope there is a way to make them add up ;-).. If you added the srcLang and trgLang like this, " unit " : [ { " id " : " u1 " , "srcLang" : "EN", "trgLang" : "CS" " originalData " : [ { " id " : " d1 " , " data " : " [$1] " } ],  you'd need to look for a custom mechanism to make them inherit onto source and target respectively.. I guess the additional advantage of instantiating the language property on soyurce and target rather then unit is that this also where they are instantiated in XLIFF Itself and we have a sch handled Constraint that checks if it matches the root set srcLang and trgLang, so good for the pipeline that switches between JLIFF and XLIFF.. Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Wed, Mar 8, 2017 at 4:11 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: To make clear, can you post a json sample?     Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global From: David Filip [mailto: david.filip@ adaptcentre.ie ] Sent: 08 March 2017 15:57 To: Phil Ritchie < phil.ritchie@vistatec.com > Cc: Yves Savourel < ysavourel@enlaso.com >; xliff-omos@lists.oasis-open. org Subject: Re: [xliff-omos] Source and Target Language properties for Fragment   Phil, I don't want to go into the philosophical debate if inheritance is XML specific (I guess not, you can do it fairly easily on any tree graphs).. Suffice it to say that JSON is not well suited for inheritance and hence I would suggest to have the (one) language property at the source and target level (which will automatically differentiate them as source and target languages). Maybe the repetition level will be theoretically higher, but in many cases you will be exchanging fragments with just one source and target. And -more importantly- you won't need to go into the extra trouble of defining source and target language (two different) properties at the unit level and make them inherit to source and target conditionally.. I guess should be also simpler for implementers/ serializers/ deserializers   Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Wed, Mar 8, 2017 at 3:36 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   Sorry but as a side note I do not know what it is that makes inheritance a characteristic of XML and not of Json. I thought it was something employed/bestowed by the applications rather than something inherent in the format/technology. They both are graphs so I assumed hierarchy and inheritance were by-products.   Anyway, I am most interested in the practical use and size/repetition minimisation. Having the languages at the highest level just reduces both. Phil       Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global     On 8 Mar 2017, at 15:05, David Filip < david.filip@adaptcentre.ie > wrote: Phil,   since Robert can enforce defaults with his schema, I guess we could construe inheritance if we cared enough, but I don't think that our goal is to make JSON behave as XML, we just want to instantiate the properties necessary at the fragment exchange level, necessary not to break a process that switches between the XML and JSON pipelines..   If our goal was to recreate full XLIFF in JSON then we probably would have to force JSON to inherit, but we agreed that this was not our goal ;-)   Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Mon, Mar 6, 2017 at 5:05 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   With regard to "fragment" I agree with Yves' proposition that I would normally understand it to be something small and a constituent of something bigger. "resource" would also have other connotations. How about "section" or "subset"? Can we not introduce the concept of inheritance? >   Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global  


  • 9.  RE: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-09-2017 15:57
    David   Ouch, please, no. That’s really nasty from an implementation perspective.   Unless we want to allow multiple target languages per subunit, it would want to be more like:   " subunit " : [                 {                     " type " : " segment " ,                     " state " : " translated " ,                     " canResegment " : false ,                     “srcLang”: “EN”,                     “trgLang”: “CS”,                     " source " :                     [                         { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " },                         { " text " : " messages " }                                             ],                     " target " :                     [                         { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " },                         { " text " : " zpráv " }                                             ]                 },     Phil   Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global From: David Filip [mailto:david.filip@adaptcentre.ie] Sent: 09 March 2017 13:11 To: Phil Ritchie <phil.ritchie@vistatec.com> Cc: Yves Savourel <ysavourel@enlaso.com>; xliff-omos@lists.oasis-open.org Subject: Re: [xliff-omos] Source and Target Language properties for Fragment   Phil, taking a fragment from this Example on the jliff repo https://github.com/oasis-tcs/xliff-omos-jliff/blob/master/JLIFF-schema-draft/jliff-example1-0.9.3.json   [I removed the line that represented pc as a pair tag, as we want to represent that linearly with empty tags and that is not the point here]   " subunit " : [                 {                     " type " : " segment " ,                     " state " : " translated " ,                     " canResegment " : false ,                     " source " : [{ " lang " : " EN " }],                     [                         { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " },                         { " text " : " messages " }                                             ],                     " target " : [{ " lang " : " CS " }],                     [                         { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " },                         { " text " : " zpráv " }                                             ]                 },                 {                     " type " : " ignorable " ,                     " source " : [                        { " text " : " .  " }                     ]   If the brackets don't add up after my edit, I hope there is a way to make them add up ;-)..   If you added the srcLang and trgLang like this,   " unit " : [         {             " id " : " u1 " ,             "srcLang" : "EN",             "trgLang" : "CS"             " originalData " : [                 { " id " : " d1 " , " data " : " [$1] " }                             ],  you'd need to look for a custom mechanism to make them inherit onto source and target respectively..   I guess the additional advantage of instantiating the language property on soyurce and target rather then unit is that this also where they are instantiated in XLIFF Itself and we have a sch handled Constraint that checks if it matches the root set srcLang and trgLang, so good for the pipeline that switches between JLIFF and XLIFF..   Cheers dF       Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Wed, Mar 8, 2017 at 4:11 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   To make clear, can you post a json sample?       Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global   From: David Filip [mailto: david.filip@adaptcentre.ie ] Sent: 08 March 2017 15:57 To: Phil Ritchie < phil.ritchie@vistatec.com > Cc: Yves Savourel < ysavourel@enlaso.com >; xliff-omos@lists.oasis-open.org Subject: Re: [xliff-omos] Source and Target Language properties for Fragment   Phil, I don't want to go into the philosophical debate if inheritance is XML specific (I guess not, you can do it fairly easily on any tree graphs).. Suffice it to say that JSON is not well suited for inheritance and hence I would suggest to have the (one) language property at the source and target level (which will automatically differentiate them as source and target languages). Maybe the repetition level will be theoretically higher, but in many cases you will be exchanging fragments with just one source and target. And -more importantly- you won't need to go into the extra trouble of defining source and target language (two different) properties at the unit level and make them inherit to source and target conditionally.. I guess should be also simpler for implementers/ serializers/ deserializers   Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Wed, Mar 8, 2017 at 3:36 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   Sorry but as a side note I do not know what it is that makes inheritance a characteristic of XML and not of Json. I thought it was something employed/bestowed by the applications rather than something inherent in the format/technology. They both are graphs so I assumed hierarchy and inheritance were by-products.   Anyway, I am most interested in the practical use and size/repetition minimisation. Having the languages at the highest level just reduces both. Phil       Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global     On 8 Mar 2017, at 15:05, David Filip < david.filip@adaptcentre.ie > wrote: Phil,   since Robert can enforce defaults with his schema, I guess we could construe inheritance if we cared enough, but I don't think that our goal is to make JSON behave as XML, we just want to instantiate the properties necessary at the fragment exchange level, necessary not to break a process that switches between the XML and JSON pipelines..   If our goal was to recreate full XLIFF in JSON then we probably would have to force JSON to inherit, but we agreed that this was not our goal ;-)   Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Mon, Mar 6, 2017 at 5:05 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   With regard to "fragment" I agree with Yves' proposition that I would normally understand it to be something small and a constituent of something bigger. "resource" would also have other connotations. How about "section" or "subset"? Can we not introduce the concept of inheritance? >   Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global  


  • 10.  Re: [xliff-omos] Source and Target Language properties for Fragment

    Posted 03-09-2017 19:31
    Phil, your proposal also doesn't prevent subunits (segments or ignorables) with different source or target languages within a unit. If you want to prevent that you really have to place it as per my second snippet. Remember, that "subunit" should be rather "subunits" in the JSON schema as per the other thread. We are back to the trade off, either have it on the top level of the fragment and than wonder about inheritance or have it as close to the source and target and fear mixed language units.. We could have both to be absolutely sure.. Cheers,  Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Thu, Mar 9, 2017 at 3:56 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: David   Ouch, please, no. That’s really nasty from an implementation perspective.   Unless we want to allow multiple target languages per subunit, it would want to be more like:   " subunit " : [                 {                     " type " : " segment " ,                     " state " : " translated " ,                     " canResegment " : false ,                     “srcLang”: “EN”,                     “trgLang”: “CS”,                     " source " :                     [                         { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " },                         { " text " : " messages " }                                             ],                     " target " :                     [                         { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " },                         { " text " : " zpráv " }                                             ]                 },     Phil   Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global From: David Filip [mailto: david.filip@ adaptcentre.ie ] Sent: 09 March 2017 13:11 To: Phil Ritchie < phil.ritchie@vistatec.com > Cc: Yves Savourel < ysavourel@enlaso.com >; xliff-omos@lists.oasis-open. org Subject: Re: [xliff-omos] Source and Target Language properties for Fragment   Phil, taking a fragment from this Example on the jliff repo https://github.com/oasis-tcs/ xliff-omos-jliff/blob/master/ JLIFF-schema-draft/jliff- example1-0.9.3.json   [I removed the line that represented pc as a pair tag, as we want to represent that linearly with empty tags and that is not the point here]   " subunit " : [                 {                     " type " : " segment " ,                     " state " : " translated " ,                     " canResegment " : false ,                     " source " : [{ " lang " : " EN " }],                     [                         { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " },                         { " text " : " messages " }                                             ],                     " target " : [{ " lang " : " CS " }],                     [                         { " id " : " c1 " , " kind " : " ph " , " dataRef " : " d1 " },                         { " text " : " zpráv " }                                             ]                 },                 {                     " type " : " ignorable " ,                     " source " : [                        { " text " : " .  " }                     ]   If the brackets don't add up after my edit, I hope there is a way to make them add up ;-)..   If you added the srcLang and trgLang like this,   " unit " : [         {             " id " : " u1 " ,             "srcLang" : "EN",             "trgLang" : "CS"             " originalData " : [                 { " id " : " d1 " , " data " : " [$1] " }                             ],  you'd need to look for a custom mechanism to make them inherit onto source and target respectively..   I guess the additional advantage of instantiating the language property on soyurce and target rather then unit is that this also where they are instantiated in XLIFF Itself and we have a sch handled Constraint that checks if it matches the root set srcLang and trgLang, so good for the pipeline that switches between JLIFF and XLIFF..   Cheers dF       Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Wed, Mar 8, 2017 at 4:11 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   To make clear, can you post a json sample?       Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global   From: David Filip [mailto: david.filip@ adaptcentre.ie ] Sent: 08 March 2017 15:57 To: Phil Ritchie < phil.ritchie@vistatec.com > Cc: Yves Savourel < ysavourel@enlaso.com >; xliff-omos@lists.oasis-open. org Subject: Re: [xliff-omos] Source and Target Language properties for Fragment   Phil, I don't want to go into the philosophical debate if inheritance is XML specific (I guess not, you can do it fairly easily on any tree graphs).. Suffice it to say that JSON is not well suited for inheritance and hence I would suggest to have the (one) language property at the source and target level (which will automatically differentiate them as source and target languages). Maybe the repetition level will be theoretically higher, but in many cases you will be exchanging fragments with just one source and target. And -more importantly- you won't need to go into the extra trouble of defining source and target language (two different) properties at the unit level and make them inherit to source and target conditionally.. I guess should be also simpler for implementers/ serializers/ deserializers   Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Wed, Mar 8, 2017 at 3:36 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   Sorry but as a side note I do not know what it is that makes inheritance a characteristic of XML and not of Json. I thought it was something employed/bestowed by the applications rather than something inherent in the format/technology. They both are graphs so I assumed hierarchy and inheritance were by-products.   Anyway, I am most interested in the practical use and size/repetition minimisation. Having the languages at the highest level just reduces both. Phil       Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global     On 8 Mar 2017, at 15:05, David Filip < david.filip@adaptcentre.ie > wrote: Phil,   since Robert can enforce defaults with his schema, I guess we could construe inheritance if we cared enough, but I don't think that our goal is to make JSON behave as XML, we just want to instantiate the properties necessary at the fragment exchange level, necessary not to break a process that switches between the XML and JSON pipelines..   If our goal was to recreate full XLIFF in JSON then we probably would have to force JSON to inherit, but we agreed that this was not our goal ;-)   Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122     On Mon, Mar 6, 2017 at 5:05 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   With regard to "fragment" I agree with Yves' proposition that I would normally understand it to be something small and a constituent of something bigger. "resource" would also have other connotations. How about "section" or "subset"? Can we not introduce the concept of inheritance? >   Phil Ritchie Chief Technology Officer     Vistatec Vistatec House, 700 South  Circular Road, Kilmainham, Dublin 8, Ireland. Tel:  +353 1 416 8000     Direct:  +353 1 416 8024 Email:  phil.ritchie@vistatec.com www.vistatec.com     ISO 9001     ISO 13485     ISO 17100 Think Global  


  • 11.  Re: [xliff-omos] Source and Target Language properties for Fragment