I am jumping in a few days late. I'm also not sure why inheritance is or isn't more innate in XML vs JSON, other than the fact that people typically declare XML structures to have inherited properties, and do so less often with JSON. But JSON people do talk about scope , which for our purposes is pretty similar. From a practical standpoint, we need to balance 2 design concerns (and possibly others): Allowing sufficient expressibility to represent the OM Avoiding the need to repetitively re-declare every piece of metadata at every valid location. (ie, allow JLIFF to be concise where possible) The overwhelmingly dominant use case for *LIFF is data that's strictly bilingual. XLIFF allows for xml:lang values on source/target that deviate from srcLang/trgLang (although I'm not entirely sure why), as well as on other elements (where the use cases from extensions are much easier to imagine). Is there really an argument that we need to redundantly declare identical srcLang/trgLang values on every unit? Why? On Thu, Mar 9, 2017 at 11:30 AM, David Filip <
david.filip@adaptcentre.ie > wrote: 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 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 From: David Filip [mailto: david.filip@adaptcentr e.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.or g 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/x liff-omos-jliff/blob/master/JL IFF-schema-draft/jliff-example 1-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 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 From: David Filip [mailto: david.filip@adaptcentr e.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.or g 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 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 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
Original Message----- > From: xliff-omos@lists.oasis-open.or g [mailto: xliff-omos@lists.oasis - > open.org ] On Behalf Of Yves Savourel > Sent: 06 March 2017 16:08 > To: xliff-omos@lists.oasis-open.or g > Subject: RE: [xliff-omos] Source and Target Language properties for > Fragment > > 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/x liff- > omos-jliff/blob/master/JLIFF-s chema-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.or g [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.or g > 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 > > > > > > > > > > > ------------------------------ ------------------------------ --------- > 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/po rtal/my_workgroups.php