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

Hi Robert, Phil,  On Oct 22, 2017 03:58, "Robert van Engelen" < engelen@genivia.com > wrote: In my implementation has a (possibly undesirable) by-product which is that “root” can contain all four types together. I agree with Phil that this is undesirable.. Besides that “root” can contain all four types, it can also contain repeated types, correct? Say two files and three units? This type of repetition shouldn't be allowed.  This can be modeled with a schema, though I wonder how different this will be from the OM (and xliff) design plans? This is very different from the OM and would not be interoperable with the XML pipeline. You'd need to expand multiple coresponding XLIFF files when going XML. And I don't think we want to go there.  Each JLIFF should have just a single instance of root content..  The values governing what type this instance is should not repeat the names from the lower level, because the reason to introduce the root content characteristics was that the lower level content was ambiguous from the OM point of view.  I agree that “root” should really be a container, which is a natural fit for your example serialization, i.e. simply call it “data” or “content”, where the latter was suggested before. So this is correct, just that the values to govern the content selection should be and map like this liff -> content must be "files" file/fragment ->  content should be an unlimited choice group of "groups" and "units" OR we could introduce "subfiles" (by analogy tu "subunits" which can intermix segments and ignorables)  that could intermix group and unit content objects.  group -> content should be an unlimited choice group of "groups" and "units" OR we could introduce "subgroups" that could intermix group and unit content objects.  Now that I wrote all of the above, it seem to me that we could and should get rid of the top level content property by simply introducing more content types. This makes the content unambiguous from the OM and XLIFF points of view.  We'd have "files" which equals liff in OM, "subfiles" which equals file, "subgroups" which equals group. And "subunits" for unit. "subfiles" and "subgroups" have exactly the same data model in JLIFF, which is fine because they have the same models in OM. We just call them differently to preserve the OM level, which is critical for switching pipelines..  Cheers dF    From:   Robert van Engelen [ mailto:engelen@genivia.com ]   Sent:   Saturday 21 October 2017 21:50 To:   Phil Ritchie < phil.ritchie@vistatec.com > Cc:   xliff-omos@lists.oasis- open.org Subject:   Re: [xliff-omos] Changes to schema discussed in last meeting.   Phil,  My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level.   Great.   Am I correct to assume you’re good with the following example of the approach we discussed, i.e. adding “root” and “type” properties at the top level?   {   "jliff": "2.1",   "srcLang": "en",   "trgLang": "fr”,   “type”: “files”,   “root” {     "files": [       {         "id": "fl",         "units": [       etc. An alternative would be to put “type” under “root"   {   "jliff": "2.1",   "srcLang": "en",   "trgLang": "fr”,   “root” {     “type”: “files”,       "files": [       {         "id": "fl",         "units": [       etc.   There are other ways to convey the type of the content. What is the preferred structure in your case?       Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676    engelen@genivia.com   On Oct 15, 2017, at 10:15 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   All Apologies for my public stream of consciousness last week around whether to implement the schema changes or not. My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level. 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland . The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).   ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.   If you have received this message in error please notify the sender immediately.

OK, then it is now clear to me that I did not fully understand the nature/purpose/use case of different "root" types. :-( 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland. The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s). ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden. If you have received this message in error please notify the sender immediately.   From: David Filip <david.filip@adaptcentre.ie> Sent: 23 October 2017 02:00:33 To: Robert van Engelen Cc: Phil Ritchie; XLIFF OMOS TC Subject: Re: [xliff-omos] Changes to schema discussed in last meeting.   Hi Robert, Phil,  On Oct 22, 2017 03:58, "Robert van Engelen" < engelen@genivia.com > wrote: In my implementation has a (possibly undesirable) by-product which is that “root” can contain all four types together. I agree with Phil that this is undesirable.. Besides that “root” can contain all four types, it can also contain repeated types, correct? Say two files and three units? This type of repetition shouldn't be allowed.  This can be modeled with a schema, though I wonder how different this will be from the OM (and xliff) design plans? This is very different from the OM and would not be interoperable with the XML pipeline. You'd need to expand multiple coresponding XLIFF files when going XML. And I don't think we want to go there.  Each JLIFF should have just a single instance of root content..  The values governing what type this instance is should not repeat the names from the lower level, because the reason to introduce the root content characteristics was that the lower level content was ambiguous from the OM point of view.  I agree that “root” should really be a container, which is a natural fit for your example serialization, i.e. simply call it “data” or “content”, where the latter was suggested before. So this is correct, just that the values to govern the content selection should be and map like this liff -> content must be "files" file/fragment ->  content should be an unlimited choice group of "groups" and "units" OR we could introduce "subfiles" (by analogy tu "subunits" which can intermix segments and ignorables)  that could intermix group and unit content objects.  group -> content should be an unlimited choice group of "groups" and "units" OR we could introduce "subgroups" that could intermix group and unit content objects.  Now that I wrote all of the above, it seem to me that we could and should get rid of the top level content property by simply introducing more content types. This makes the content unambiguous from the OM and XLIFF points of view.  We'd have "files" which equals liff in OM, "subfiles" which equals file, "subgroups" which equals group. And "subunits" for unit. "subfiles" and "subgroups" have exactly the same data model in JLIFF, which is fine because they have the same models in OM. We just call them differently to preserve the OM level, which is critical for switching pipelines..  Cheers dF    From:   Robert van Engelen [ mailto:engelen@genivia.com ]   Sent:   Saturday 21 October 2017 21:50 To:   Phil Ritchie < phil.ritchie@vistatec.com > Cc:   xliff-omos@lists.oasis- open.org Subject:   Re: [xliff-omos] Changes to schema discussed in last meeting.   Phil,  My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level.   Great.   Am I correct to assume you’re good with the following example of the approach we discussed, i.e. adding “root” and “type” properties at the top level?   {   "jliff": "2.1",   "srcLang": "en",   "trgLang": "fr”,   “type”: “files”,   “root” {     "files": [       {         "id": "fl",         "units": [       etc. An alternative would be to put “type” under “root"   {   "jliff": "2.1",   "srcLang": "en",   "trgLang": "fr”,   “root” {     “type”: “files”,       "files": [       {         "id": "fl",         "units": [       etc.   There are other ways to convey the type of the content. What is the preferred structure in your case?       Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676    engelen@genivia.com   On Oct 15, 2017, at 10:15 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   All Apologies for my public stream of consciousness last week around whether to implement the schema changes or not. My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level. 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland . The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).   ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.   If you have received this message in error please notify the sender immediately.

Hi, To continue the discussion on root content meta-types in JLIFF JSON payloads (“fragment”, “units”, “groups” etc), I am growing more uncomfortable with an approach that requires explicit meta-type information in the payload e.g. using a “type attribute” when in fact the meta-type of the root content is immediately defined by the property name at the root level that we choose for the various possible roots. For example, the “units” root is used in jliff-example4.json as follows: {     jliff : 2.1 ,     srcLang : en ,     trgLang : de ,     units : [         {             id : u1 ,             subunits : [ Since “units” determines the root content of the payload, it is not clear why other meta-type information is necessary. Can someone clarify? Note that the property names of the roots that we currently support in JLIFF schema 0.9.4 are: - “files” contains an array of fragments - “fragment” contains an object with id, original, skeleton, units and metadata - “groups” contains an array of groups but this is not (yet) defined in JLIFF 0.9.4 (perhaps an oversight? Do we need this?) - “units” contains an array of “unit” objects - “subunits” contains an array of “subunit” objects On a related note, since “files” is an array of fragments, we should perhaps remove the “fragment” root and use “files” instead with a singleton fragment. This improves orthogonality of the model design with only one way to include a single fragment instead of two ways. Cheers, - Robert   Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676   LinkedIn: www.linkedin.com/in/robertvanengelen/    engelen@genivia.com On Oct 23, 2017, at 1:47 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: OK, then it is now clear to me that I did not fully understand the nature/purpose/use case of different root types. :-( 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland. The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s). ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden. If you have received this message in error please notify the sender immediately.   From: David Filip < david.filip@adaptcentre.ie > Sent: 23 October 2017 02:00:33 To: Robert van Engelen Cc: Phil Ritchie; XLIFF OMOS TC Subject: Re: [xliff-omos] Changes to schema discussed in last meeting.   Hi Robert, Phil,  On Oct 22, 2017 03:58, Robert van Engelen < engelen@genivia.com > wrote: In my implementation has a (possibly undesirable) by-product which is that “root” can contain all four types together. I agree with Phil that this is undesirable.. Besides that “root” can contain all four types, it can also contain repeated types, correct? Say two files and three units? This type of repetition shouldn't be allowed.  This can be modeled with a schema, though I wonder how different this will be from the OM (and xliff) design plans? This is very different from the OM and would not be interoperable with the XML pipeline. You'd need to expand multiple coresponding XLIFF files when going XML. And I don't think we want to go there.  Each JLIFF should have just a single instance of root content..  The values governing what type this instance is should not repeat the names from the lower level, because the reason to introduce the root content characteristics was that the lower level content was ambiguous from the OM point of view.  I agree that “root” should really be a container, which is a natural fit for your example serialization, i.e. simply call it “data” or “content”, where the latter was suggested before. So this is correct, just that the values to govern the content selection should be and map like this liff -> content must be files file/fragment ->  content should be an unlimited choice group of groups and units OR we could introduce subfiles (by analogy tu subunits which can intermix segments and ignorables)  that could intermix group and unit content objects.  group -> content should be an unlimited choice group of groups and units OR we could introduce subgroups that could intermix group and unit content objects.  Now that I wrote all of the above, it seem to me that we could and should get rid of the top level content property by simply introducing more content types. This makes the content unambiguous from the OM and XLIFF points of view.  We'd have files which equals liff in OM, subfiles which equals file, subgroups which equals group. And subunits for unit. subfiles and subgroups have exactly the same data model in JLIFF, which is fine because they have the same models in OM. We just call them differently to preserve the OM level, which is critical for switching pipelines..  Cheers dF    From:   Robert van Engelen [ mailto:engelen@genivia.com ]   Sent:   Saturday 21 October 2017 21:50 To:   Phil Ritchie < phil.ritchie@vistatec.com > Cc:   xliff-omos@lists.oasis- open.org Subject:   Re: [xliff-omos] Changes to schema discussed in last meeting.   Phil,  My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level.   Great.   Am I correct to assume you’re good with the following example of the approach we discussed, i.e. adding “root” and “type” properties at the top level?   {   jliff : 2.1 ,   srcLang : en ,   trgLang : fr”,   “type”: “files”,   “root” {     files : [       {          id : fl ,         units : [       etc. An alternative would be to put “type” under “root   {    jliff : 2.1 ,    srcLang : en ,    trgLang : fr”,   “root” {     “type”: “files”,        files : [       {          id : fl ,          units : [       etc.   There are other ways to convey the type of the content. What is the preferred structure in your case?       Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676    engelen@genivia.com   On Oct 15, 2017, at 10:15 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   All Apologies for my public stream of consciousness last week around whether to implement the schema changes or not. My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level. 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland . The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).   ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.   If you have received this message in error please notify the sender immediately.

Hi Phil et al. The JLIFF repo is updated: https://github.com/oasis-tcs/xliff-omos-jliff/tree/master/JLIFF-schema-draft A JLIFF root is on of these three choices: Files array of file (fragment)   Subfiles array of subfile     Unit or group (a subfile) identified by “kind”:”unit” (default) or “kind”:”group”       Subunits in case of unit       Subfiles in case of group, an array of subfile (unit or group) Subfiles array of subfile   Unit or group (a subfile) identified by “kind”:”unit” (default) or “kind”:”group”     Subunits in case of unit     Subfiles in case of group, an array of subfile (unit or group) Subunits I believe this captures our conversation. I could not use “type” to identify “unit” or “group” since “type” is a property of the unit and group types. I think “kind” works fine. I also updated the XLIFF-JLIFF wiki page to reflect this structure: https://github.com/oasis-tcs/xliff-omos-om/wiki I’ve updated the examples to reflect the use of “subfiles” and added a 5th example that highlights the use of “kind”:”group”. The list of changes (see also the README): - added `subfiles` array type and `subfile` object type with unit or group content identified by ` kind : unit group ` where ` unit ` is the default, using ` kind ` instead of ` type ` due to a name clash; - changed ` type : segment ignorable ` to ` kind : segment ignorable ` for consistency of the ` kind ` type selector; - changed `fragment` to `file` for sake of naming consistency; - reduced top-level jliff type choices to three: ` files `, ` subfiles `, and ` subunits”`; - added ` NMTOKEN ` type for ` id ` values with value space identical to XLIFF id NMTOKEN values. Thanks and enjoy!   Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676   LinkedIn: www.linkedin.com/in/robertvanengelen/    engelen@genivia.com On Oct 23, 2017, at 1:47 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: OK, then it is now clear to me that I did not fully understand the nature/purpose/use case of different root types. :-( 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland. The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s). ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden. If you have received this message in error please notify the sender immediately.   From: David Filip < david.filip@adaptcentre.ie > Sent: 23 October 2017 02:00:33 To: Robert van Engelen Cc: Phil Ritchie; XLIFF OMOS TC Subject: Re: [xliff-omos] Changes to schema discussed in last meeting.   Hi Robert, Phil,  On Oct 22, 2017 03:58, Robert van Engelen < engelen@genivia.com > wrote: In my implementation has a (possibly undesirable) by-product which is that “root” can contain all four types together. I agree with Phil that this is undesirable.. Besides that “root” can contain all four types, it can also contain repeated types, correct? Say two files and three units? This type of repetition shouldn't be allowed.  This can be modeled with a schema, though I wonder how different this will be from the OM (and xliff) design plans? This is very different from the OM and would not be interoperable with the XML pipeline. You'd need to expand multiple coresponding XLIFF files when going XML. And I don't think we want to go there.  Each JLIFF should have just a single instance of root content..  The values governing what type this instance is should not repeat the names from the lower level, because the reason to introduce the root content characteristics was that the lower level content was ambiguous from the OM point of view.  I agree that “root” should really be a container, which is a natural fit for your example serialization, i.e. simply call it “data” or “content”, where the latter was suggested before. So this is correct, just that the values to govern the content selection should be and map like this liff -> content must be files file/fragment ->  content should be an unlimited choice group of groups and units OR we could introduce subfiles (by analogy tu subunits which can intermix segments and ignorables)  that could intermix group and unit content objects.  group -> content should be an unlimited choice group of groups and units OR we could introduce subgroups that could intermix group and unit content objects.  Now that I wrote all of the above, it seem to me that we could and should get rid of the top level content property by simply introducing more content types. This makes the content unambiguous from the OM and XLIFF points of view.  We'd have files which equals liff in OM, subfiles which equals file, subgroups which equals group. And subunits for unit. subfiles and subgroups have exactly the same data model in JLIFF, which is fine because they have the same models in OM. We just call them differently to preserve the OM level, which is critical for switching pipelines..  Cheers dF    From:   Robert van Engelen [ mailto:engelen@genivia.com ]   Sent:   Saturday 21 October 2017 21:50 To:   Phil Ritchie < phil.ritchie@vistatec.com > Cc:   xliff-omos@lists.oasis- open.org Subject:   Re: [xliff-omos] Changes to schema discussed in last meeting.   Phil,  My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level.   Great.   Am I correct to assume you’re good with the following example of the approach we discussed, i.e. adding “root” and “type” properties at the top level?   {   jliff : 2.1 ,   srcLang : en ,   trgLang : fr”,   “type”: “files”,   “root” {     files : [       {          id : fl ,         units : [       etc. An alternative would be to put “type” under “root   {    jliff : 2.1 ,    srcLang : en ,    trgLang : fr”,   “root” {     “type”: “files”,        files : [       {          id : fl ,          units : [       etc.   There are other ways to convey the type of the content. What is the preferred structure in your case?       Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676    engelen@genivia.com   On Oct 15, 2017, at 10:15 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   All Apologies for my public stream of consciousness last week around whether to implement the schema changes or not. My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level. 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland . The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).   ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.   If you have received this message in error please notify the sender immediately.

Thanks Robert. I was able to implement most of this so far. My unit tests produce mirrors of your hand crafted examples and I’m just treble checking they align.   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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland. The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s). ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden. If you have received this message in error please notify the sender immediately.   From: Robert van Engelen [mailto:engelen@genivia.com] Sent: Thursday 16 November 2017 21:18 To: Phil Ritchie <phil.ritchie@vistatec.com> Cc: David Filip <david.filip@adaptcentre.ie>; XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] Changes to schema discussed in last meeting.     Hi Phil et al.   The JLIFF repo is updated:   https://github.com/oasis-tcs/xliff-omos-jliff/tree/master/JLIFF-schema-draft   A JLIFF root is on of these three choices:   Files array of file (fragment)   Subfiles array of subfile     Unit or group (a subfile) identified by “kind”:”unit” (default) or “kind”:”group”       Subunits in case of unit       Subfiles in case of group, an array of subfile (unit or group)   Subfiles array of subfile   Unit or group (a subfile) identified by “kind”:”unit” (default) or “kind”:”group”     Subunits in case of unit     Subfiles in case of group, an array of subfile (unit or group)   Subunits   I believe this captures our conversation. I could not use “type” to identify “unit” or “group” since “type” is a property of the unit and group types. I think “kind” works fine.   I also updated the XLIFF-JLIFF wiki page to reflect this structure:   https://github.com/oasis-tcs/xliff-omos-om/wiki   I’ve updated the examples to reflect the use of “subfiles” and added a 5th example that highlights the use of “kind”:”group”.   The list of changes (see also the README):   - added `subfiles` array type and `subfile` object type with unit or group content identified by `"kind": "unit" "group"` where `"unit"` is the default, using `"kind"` instead of `"type"` due to a name clash; - changed `"type": "segment" "ignorable"` to `"kind": "segment" "ignorable"` for consistency of the `"kind"` type selector; - changed `fragment` to `file` for sake of naming consistency; - reduced top-level jliff type choices to three: `"files"`, `"subfiles"`, and `"subunits”`; - added `"NMTOKEN"` type for `"id"` values with value space identical to XLIFF id NMTOKEN values.   Thanks and enjoy!     Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676   LinkedIn: www.linkedin.com/in/robertvanengelen/    engelen@genivia.com   On Oct 23, 2017, at 1:47 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   OK, then it is now clear to me that I did not fully understand the nature/purpose/use case of different "root" types. :-(   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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland. The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s). ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden. If you have received this message in error please notify the sender immediately.     From: David Filip < david.filip@adaptcentre.ie > Sent: 23 October 2017 02:00:33 To: Robert van Engelen Cc: Phil Ritchie; XLIFF OMOS TC Subject: Re: [xliff-omos] Changes to schema discussed in last meeting.   Hi Robert, Phil,    On Oct 22, 2017 03:58, "Robert van Engelen" < engelen@genivia.com > wrote: In my implementation has a (possibly undesirable) by-product which is that “root” can contain all four types together. I agree with Phil that this is undesirable..   Besides that “root” can contain all four types, it can also contain repeated types, correct? Say two files and three units? This type of repetition shouldn't be allowed.  This can be modeled with a schema, though I wonder how different this will be from the OM (and xliff) design plans? This is very different from the OM and would not be interoperable with the XML pipeline. You'd need to expand multiple coresponding XLIFF files when going XML. And I don't think we want to go there.  Each JLIFF should have just a single instance of root content..  The values governing what type this instance is should not repeat the names from the lower level, because the reason to introduce the root content characteristics was that the lower level content was ambiguous from the OM point of view.      I agree that “root” should really be a container, which is a natural fit for your example serialization, i.e. simply call it “data” or “content”, where the latter was suggested before. So this is correct, just that the values to govern the content selection should be and map like this liff -> content must be "files" file/fragment ->  content should be an unlimited choice group of "groups" and "units" OR we could introduce "subfiles" (by analogy tu "subunits" which can intermix segments and ignorables)  that could intermix group and unit content objects.  group -> content should be an unlimited choice group of "groups" and "units" OR we could introduce "subgroups" that could intermix group and unit content objects.      Now that I wrote all of the above, it seem to me that we could and should get rid of the top level content property by simply introducing more content types. This makes the content unambiguous from the OM and XLIFF points of view.  We'd have "files" which equals liff in OM, "subfiles" which equals file, "subgroups" which equals group. And "subunits" for unit. "subfiles" and "subgroups" have exactly the same data model in JLIFF, which is fine because they have the same models in OM. We just call them differently to preserve the OM level, which is critical for switching pipelines..    Cheers dF            From:   Robert van Engelen [ mailto:engelen@genivia.com ]   Sent:   Saturday 21 October 2017 21:50 To:   Phil Ritchie < phil.ritchie@vistatec.com > Cc:   xliff-omos@lists.oasis-open.org Subject:   Re: [xliff-omos] Changes to schema discussed in last meeting.   Phil,    My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level.   Great.   Am I correct to assume you’re good with the following example of the approach we discussed, i.e. adding “root” and “type” properties at the top level?   {   "jliff": "2.1",   "srcLang": "en",   "trgLang": "fr”,   “type”: “files”,   “root” {     "files": [       {         "id": "fl",         "units": [       etc. An alternative would be to put “type” under “root"   {   "jliff": "2.1",   "srcLang": "en",   "trgLang": "fr”,   “root” {     “type”: “files”,       "files": [       {         "id": "fl",         "units": [       etc.   There are other ways to convey the type of the content. What is the preferred structure in your case?       Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676    engelen@genivia.com   On Oct 15, 2017, at 10:15 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   All Apologies for my public stream of consciousness last week around whether to implement the schema changes or not. My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level. 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland . The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).   ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.   If you have received this message in error please notify the sender immediately.        

Good to know and thanks for checking! - Robert   Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676   LinkedIn: www.linkedin.com/in/robertvanengelen/    engelen@genivia.com On Nov 21, 2017, at 12:18 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: Thanks Robert. I was able to implement most of this so far. My unit tests produce mirrors of your hand crafted examples and I’m just treble checking they align.   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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland. The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).   ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.   If you have received this message in error please notify the sender immediately.   From:   Robert van Engelen [ mailto:engelen@genivia.com ]   Sent:   Thursday 16 November 2017 21:18 To:   Phil Ritchie < phil.ritchie@vistatec.com > Cc:   David Filip < david.filip@adaptcentre.ie >; XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   Re: [xliff-omos] Changes to schema discussed in last meeting.     Hi Phil et al.   The JLIFF repo is updated:   https://github.com/oasis-tcs/xliff-omos-jliff/tree/master/JLIFF-schema-draft   A JLIFF root is on of these three choices:   Files array of file (fragment)   Subfiles array of subfile     Unit or group (a subfile) identified by “kind”:”unit” (default) or “kind”:”group”       Subunits in case of unit       Subfiles in case of group, an array of subfile (unit or group)   Subfiles array of subfile   Unit or group (a subfile) identified by “kind”:”unit” (default) or “kind”:”group”     Subunits in case of unit     Subfiles in case of group, an array of subfile (unit or group)   Subunits   I believe this captures our conversation. I could not use “type” to identify “unit” or “group” since “type” is a property of the unit and group types. I think “kind” works fine.   I also updated the XLIFF-JLIFF wiki page to reflect this structure:   https://github.com/oasis-tcs/xliff-omos-om/wiki   I’ve updated the examples to reflect the use of “subfiles” and added a 5th example that highlights the use of “kind”:”group”.   The list of changes (see also the README):   - added `subfiles` array type and `subfile` object type with unit or group content identified by ` kind : unit group ` where ` unit ` is the default, using ` kind ` instead of ` type ` due to a name clash; - changed ` type : segment ignorable ` to ` kind : segment ignorable ` for consistency of the ` kind ` type selector; - changed `fragment` to `file` for sake of naming consistency; - reduced top-level jliff type choices to three: ` files `, ` subfiles `, and ` subunits”`; - added ` NMTOKEN ` type for ` id ` values with value space identical to XLIFF id NMTOKEN values.   Thanks and enjoy!     Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice: (850) 270 6179 ext 104   fax: (850) 270 6179   mobile: (850) 264 2676   LinkedIn:   www.linkedin.com/in/robertvanengelen/    engelen@genivia.com   On Oct 23, 2017, at 1:47 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   OK, then it is now clear to me that I did not fully understand the nature/purpose/use case of different root types. :-(   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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland. The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).   ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.   If you have received this message in error please notify the sender immediately.     From:   David Filip < david.filip@adaptcentre.ie > Sent:   23 October 2017 02:00:33 To:   Robert van Engelen Cc:   Phil Ritchie; XLIFF OMOS TC Subject:   Re: [xliff-omos] Changes to schema discussed in last meeting.     Hi Robert, Phil,    On Oct 22, 2017 03:58, Robert van Engelen < engelen@genivia.com > wrote: In my implementation has a (possibly undesirable) by-product which is that “root” can contain all four types together. I agree with Phil that this is undesirable..   Besides that “root” can contain all four types, it can also contain repeated types, correct? Say two files and three units? This type of repetition shouldn't be allowed.  This can be modeled with a schema, though I wonder how different this will be from the OM (and xliff) design plans? This is very different from the OM and would not be interoperable with the XML pipeline. You'd need to expand multiple coresponding XLIFF files when going XML. And I don't think we want to go there.  Each JLIFF should have just a single instance of root content..  The values governing what type this instance is should not repeat the names from the lower level, because the reason to introduce the root content characteristics was that the lower level content was ambiguous from the OM point of view.      I agree that “root” should really be a container, which is a natural fit for your example serialization, i.e. simply call it “data” or “content”, where the latter was suggested before. So this is correct, just that the values to govern the content selection should be and map like this liff -> content must be files file/fragment ->  content should be an unlimited choice group of groups and units OR we could introduce subfiles (by analogy tu subunits which can intermix segments and ignorables)  that could intermix group and unit content objects.  group -> content should be an unlimited choice group of groups and units OR we could introduce subgroups that could intermix group and unit content objects.      Now that I wrote all of the above, it seem to me that we could and should get rid of the top level content property by simply introducing more content types. This makes the content unambiguous from the OM and XLIFF points of view.  We'd have files which equals liff in OM, subfiles which equals file, subgroups which equals group. And subunits for unit. subfiles and subgroups have exactly the same data model in JLIFF, which is fine because they have the same models in OM. We just call them differently to preserve the OM level, which is critical for switching pipelines..    Cheers dF            From:   Robert van Engelen [ mailto:engelen@genivia.com ]   Sent:   Saturday 21 October 2017 21:50 To:   Phil Ritchie < phil.ritchie@vistatec.com > Cc:   xliff-omos@lists.oasis-open.org Subject:   Re: [xliff-omos] Changes to schema discussed in last meeting.   Phil,    My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level.   Great.   Am I correct to assume you’re good with the following example of the approach we discussed, i.e. adding “root” and “type” properties at the top level?   {   jliff : 2.1 ,   srcLang : en ,   trgLang : fr”,   “type”: “files”,   “root” {     files : [       {          id : fl ,         units : [       etc. An alternative would be to put “type” under “root   {    jliff : 2.1 ,    srcLang : en ,    trgLang : fr”,   “root” {     “type”: “files”,        files : [       {          id : fl ,          units : [       etc.   There are other ways to convey the type of the content. What is the preferred structure in your case?       Dr. Robert van Engelen, CEO/CTO Genivia Inc.   voice:   (850) 270 6179 ext 104   fax:   (850) 270 6179   mobile:   (850) 264 2676    engelen@genivia.com   On Oct 15, 2017, at 10:15 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   All Apologies for my public stream of consciousness last week around whether to implement the schema changes or not. My motivations were good in that I didn't want people doing unnecessary work. Anyway I got all my code issues sorted and everything we discussed still stands so all good to make the schema and example changes. The only difference is that fragment, unit, subunit and group need to have a 'type' property not a single 'type' property at jliff level. 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     ISO 27001 Think Global Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700,   South Circular Road, Kilmainham. Dublin 8. Ireland . The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).   ?The unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.   If you have received this message in error please notify the sender immediately.