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

Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                "urn:oasis:names:tc:xliff:glossary:2.0:glossary": [                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:id": "ge1",                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "Term text",                     "urn:oasis:names:tc:xliff:glossary:2.0:source": "Term source"                   }                 },                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "hot"                   },                   "urn:oasis:names:tc:xliff:glossary:2.0:translations": [                     {                       "urn:oasis:names:tc:xliff:glossary:2.0:text": "hyt",                       "urn:oasis:names:tc:xliff:glossary:2.0:source": "Google"                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 "gls:glossary": [                 {                   "gls:id": "ge1",                   "gls:term": {                     "gls:text": "Term text",                     "gls:source": "Term source"                   }                 },                 {                   "gls:term": {                     "gls:text": "hot"                   },                   "gls:translations": [                     {                       "gls:text": "hyt",                       "gls:source": "Google"                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  

The topic of namespaces in JSON is obviously not new, and there has been quite a few discussions about it. Some links I’ve found interesting:   ·        http://lists.xml.org/archives/xml-dev/201506/msg00024.html ·        http://www.goland.org/jsonnamespace/ ·        http://blog.bdoughan.com/2011/04/jaxb-and-json-via-jettison-namespace.html ·        https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json   A lot of things point to JSON-LD. But that would add a significant level of complexity.     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Wednesday, May 3, 2017 8:11 PM To: 'XLIFF OMOS TC' <xliff-omos@lists.oasis-open.org> Subject: [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                "urn:oasis:names:tc:xliff:glossary:2.0:glossary": [                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:id": "ge1",                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "Term text",                     "urn:oasis:names:tc:xliff:glossary:2.0:source": "Term source"                   }                 },                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "hot"                   },                   "urn:oasis:names:tc:xliff:glossary:2.0:translations": [                     {                       "urn:oasis:names:tc:xliff:glossary:2.0:text": "hyt",                       "urn:oasis:names:tc:xliff:glossary:2.0:source": "Google"                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 "gls:glossary": [                 {                   "gls:id": "ge1",                   "gls:term": {                     "gls:text": "Term text",                     "gls:source": "Term source"                   }                 },                 {                   "gls:term": {                     "gls:text": "hot"                   },                   "gls:translations": [                     {                       "gls:text": "hyt",                       "gls:source": "Google"                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  

Maybe the simplest way is to:   1)    Have a section that maps prefixes to namespace IRIs at the top of the JSON object, 2)    Use "prefix_name" where we have non-core objects.   This way, the JSON access stays relatively simple, for example:   unit.id; unit.subUnits[0].source.text; unit.gls_glossary[0]   Using “:” for the prefix separator would force us to access things like this: unit["gls:glossary"][0] which is, in my opinion, not as clean. Using “_” you can do both: unit.gls_glossary[0] or unit["gls_glossary"][0].   As for the declaration of the prefixes, it could be done in a map at the top of the JSON object.     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Thursday, May 4, 2017 5:20 AM To: 'XLIFF OMOS TC' <xliff-omos@lists.oasis-open.org> Subject: RE: [xliff-omos] Modules and extensions   The topic of namespaces in JSON is obviously not new, and there has been quite a few discussions about it. Some links I’ve found interesting:   ·        http://lists.xml.org/archives/xml-dev/201506/msg00024.html ·        http://www.goland.org/jsonnamespace/ ·        http://blog.bdoughan.com/2011/04/jaxb-and-json-via-jettison-namespace.html ·        https://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json   A lot of things point to JSON-LD. But that would add a significant level of complexity.     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: xliff-omos@lists.oasis-open.org [ mailto:xliff-omos@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Wednesday, May 3, 2017 8:11 PM To: 'XLIFF OMOS TC' < xliff-omos@lists.oasis-open.org > Subject: [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                "urn:oasis:names:tc:xliff:glossary:2.0:glossary": [                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:id": "ge1",                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "Term text",                     "urn:oasis:names:tc:xliff:glossary:2.0:source": "Term source"                   }                 },                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "hot"                   },                   "urn:oasis:names:tc:xliff:glossary:2.0:translations": [                     {                       "urn:oasis:names:tc:xliff:glossary:2.0:text": "hyt",                       "urn:oasis:names:tc:xliff:glossary:2.0:source": "Google"                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 "gls:glossary": [                 {                   "gls:id": "ge1",                   "gls:term": {                     "gls:text": "Term text",                     "gls:source": "Term source"                   }                 },                 {                   "gls:term": {                     "gls:text": "hot"                   },                   "gls:translations": [                     {                       "gls:text": "hyt",                       "gls:source": "Google"                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  

This has been vexing me as well. If we want to go with a prefix separator, the other option is to use '$', which has some traction in the JSON world as a separator/control character (for example, its usage in the JSON scheme as a reference mechanism).  It's a little more visually distinctive than "_", and is valid in JS: > a = { "a_b": 1, "a:b": 2, "a$b": 3} < Object {a_b: 1, a:b: 2, a$b: 3} > a.a_b < 1 > a.a$b < 3 > a.a:b < [doesn't work, throws an exception] The thing that's a nuisance is that because JSON processors aren't namespace-aware, any prefix resolution is entirely up to the individual implementation.  Any decent XML processor will track namespaces and make the information available to you that the element name "foo:bar" is really, for example " http://foo.com/some/schema#bar ".  (In practice, many applications ignore this and incorrectly test prefix equality against well-defined values, but at least the potential is there to do the right thing if they wanted.) In our situation, this namespace resolution is entirely up to whoever is implementing the JLIFF, and in the JS community at least, I am pessimistic about how eagerly this technique will be adopted. But it's either that, or use the other mechanisms you've suggested.  Fully-qualified element names just seems horrendous, although it would would work.  The only other option is to have well-defined prefixes with fixed mappings, which means we have to run a prefix registry. On Thu, May 4, 2017 at 7:17 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Maybe the simplest way is to:   1)    Have a section that maps prefixes to namespace IRIs at the top of the JSON object, 2)    Use "prefix_name" where we have non-core objects.   This way, the JSON access stays relatively simple, for example:   unit.id ; unit.subUnits[0].source.text; unit.gls_glossary[0]   Using “:” for the prefix separator would force us to access things like this: unit["gls:glossary"][0] which is, in my opinion, not as clean. Using “_” you can do both: unit.gls_glossary[0] or unit["gls_glossary"][0].   As for the declaration of the prefixes, it could be done in a map at the top of the JSON object.     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: xliff-omos@lists.oasis-open. org [mailto: xliff-omos@lists. oasis-open.org ] On Behalf Of Yves Savourel Sent: Thursday, May 4, 2017 5:20 AM To: 'XLIFF OMOS TC' < xliff-omos@lists.oasis-open. org > Subject: RE: [xliff-omos] Modules and extensions   The topic of namespaces in JSON is obviously not new, and there has been quite a few discussions about it. Some links I’ve found interesting:   ·        http://lists.xml.org/archives/ xml-dev/201506/msg00024.html ·        http://www.goland.org/ jsonnamespace/ ·        http://blog.bdoughan.com/2011/ 04/jaxb-and-json-via-jettison- namespace.html ·        https://www.mnot.net/blog/ 2011/10/12/thinking_about_ namespaces_in_json   A lot of things point to JSON-LD. But that would add a significant level of complexity.     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: xliff-omos@lists.oasis-open. org [ mailto:xliff-omos@lists. oasis-open.org ] On Behalf Of Yves Savourel Sent: Wednesday, May 3, 2017 8:11 PM To: 'XLIFF OMOS TC' < xliff-omos@lists.oasis-open. org > Subject: [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                "urn:oasis:names: tc:xliff:glossary:2.0: glossary": [                 {                   "urn:oasis:names:tc:xliff: glossary:2.0:id": "ge1",                   "urn:oasis:names:tc:xliff: glossary:2.0:term": {                     "urn:oasis:names:tc:xliff: glossary:2.0:text": "Term text",                     "urn:oasis:names:tc:xliff: glossary:2.0:source": "Term source"                   }                 },                 {                   "urn:oasis:names:tc:xliff: glossary:2.0:term": {                     "urn:oasis:names:tc:xliff: glossary:2.0:text": "hot"                   },                   "urn:oasis:names:tc:xliff: glossary:2.0:translations": [                     {                       "urn:oasis:names:tc:xliff: glossary:2.0:text": "hyt",                       "urn:oasis:names:tc:xliff: glossary:2.0:source": "Google"                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 "gls:glossary": [                 {                   "gls:id": "ge1",                   "gls:term": {                     "gls:text": "Term text",                     "gls:source": "Term source"                   }                 },                 {                   "gls:term": {                     "gls:text": "hot"                   },                   "gls:translations": [                     {                       "gls:text": "hyt",                       "gls:source": "Google"                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  

I really don’t like the idea but for sake of at least investigating the possibility, it is surprising to me that the json serialization library I am using (Newtonsoft) in .NET will read and write the full urn version below.   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: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: 04 May 2017 03:11 To: 'XLIFF OMOS TC' <xliff-omos@lists.oasis-open.org> Subject: [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                "urn:oasis:names:tc:xliff:glossary:2.0:glossary": [                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:id": "ge1",                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "Term text",                     "urn:oasis:names:tc:xliff:glossary:2.0:source": "Term source"                   }                 },                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "hot"                   },                   "urn:oasis:names:tc:xliff:glossary:2.0:translations": [                     {                       "urn:oasis:names:tc:xliff:glossary:2.0:text": "hyt",                       "urn:oasis:names:tc:xliff:glossary:2.0:source": "Google"                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 "gls:glossary": [                 {                   "gls:id": "ge1",                   "gls:term": {                     "gls:text": "Term text",                     "gls:source": "Term source"                   }                 },                 {                   "gls:term": {                     "gls:text": "hot"                   },                   "gls:translations": [                     {                       "gls:text": "hyt",                       "gls:source": "Google"                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  

The more I think about, the more worried I get about working with serialization frameworks if we do some sort of homegrown namespace resolution system. For example, say we take the approach of listing IRIs at the top of the document, so we have something vaguely like: {    "prefixes": { "gls" : "urn:oasis:names:tc:xliff:glossary:2.0:glossary" },    "units": [       {         "subunits": [ .... ],         "gls:glossary": { ... }       }   ] } But this means that there is no fixed name for the glossary data.  It could be "gls:glossary", or "my:glossary", or "foo:glossary", depending on how the prefix is defined.  How easily can serialization libraries handle this?  The standard approach for most of them is to declare bindings between node names and implementation classes -- but with no fixed name, this doesn't work.  With enough effort, in some libraries It's probably possible to (for example) inject a custom evaluator class into the mapping process to make these decisions on the fly based on what prefixes have been declared, but that's a lot to ask a requirement of a correct implementation.  It may not even be possible in some serialization libraries. On Wed, May 10, 2017 at 6:56 AM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: I really don’t like the idea but for sake of at least investigating the possibility, it is surprising to me that the json serialization library I am using (Newtonsoft) in .NET will read and write the full urn version below.   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: xliff-omos@lists.oasis-open. org [mailto: xliff-omos@lists. oasis-open.org ] On Behalf Of Yves Savourel Sent: 04 May 2017 03:11 To: 'XLIFF OMOS TC' < xliff-omos@lists.oasis-open. org > Subject: [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                "urn:oasis:names: tc:xliff:glossary:2.0: glossary": [                 {                   "urn:oasis:names:tc:xliff: glossary:2.0:id": "ge1",                   "urn:oasis:names:tc:xliff: glossary:2.0:term": {                     "urn:oasis:names:tc:xliff: glossary:2.0:text": "Term text",                     "urn:oasis:names:tc:xliff: glossary:2.0:source": "Term source"                   }                 },                 {                   "urn:oasis:names:tc:xliff: glossary:2.0:term": {                     "urn:oasis:names:tc:xliff: glossary:2.0:text": "hot"                   },                   "urn:oasis:names:tc:xliff: glossary:2.0:translations": [                     {                       "urn:oasis:names:tc:xliff: glossary:2.0:text": "hyt",                       "urn:oasis:names:tc:xliff: glossary:2.0:source": "Google"                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 "gls:glossary": [                 {                   "gls:id": "ge1",                   "gls:term": {                     "gls:text": "Term text",                     "gls:source": "Term source"                   }                 },                 {                   "gls:term": {                     "gls:text": "hot"                   },                   "gls:translations": [                     {                       "gls:text": "hyt",                       "gls:source": "Google"                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  

I would think that for the modules we could use the official prefixes: ‘gls’, ‘mda’, etc. they are “reserved” in the XLIFF specification. We would always know which prefix corresponds to which module. Then the mapping would tell us about which version of the module we have to work with.   For the extensions… I don’t know. But the issue is somewhat different because the reader is not necessarily knowing anything about those entries.   I know Felix suggested JSON-LD. Like we discussed during the call, it seemed to be a relatively complicated mechanism. But I don’t know it well at all.   One thing is clear: it’s not a basic serialization and using some of the automated conversion maybe not always possible.   Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: Chase Tingley [mailto:chase@spartansoftwareinc.com] Sent: Wednesday, May 10, 2017 5:48 PM To: Phil Ritchie <phil.ritchie@vistatec.com> Cc: Yves Savourel <ysavourel@enlaso.com>; XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] Modules and extensions   The more I think about, the more worried I get about working with serialization frameworks if we do some sort of homegrown namespace resolution system.   For example, say we take the approach of listing IRIs at the top of the document, so we have something vaguely like:   {    "prefixes": { "gls" : "urn:oasis:names:tc:xliff:glossary:2.0:glossary" },    "units": [       {         "subunits": [ .... ],         "gls:glossary": { ... }       }   ] }   But this means that there is no fixed name for the glossary data.  It could be "gls:glossary", or "my:glossary", or "foo:glossary", depending on how the prefix is defined.  How easily can serialization libraries handle this?  The standard approach for most of them is to declare bindings between node names and implementation classes -- but with no fixed name, this doesn't work.  With enough effort, in some libraries It's probably possible to (for example) inject a custom evaluator class into the mapping process to make these decisions on the fly based on what prefixes have been declared, but that's a lot to ask a requirement of a correct implementation.  It may not even be possible in some serialization libraries.     On Wed, May 10, 2017 at 6:56 AM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   I really don’t like the idea but for sake of at least investigating the possibility, it is surprising to me that the json serialization library I am using (Newtonsoft) in .NET will read and write the full urn version below.   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: xliff-omos@lists.oasis-open.org [mailto: xliff-omos@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: 04 May 2017 03:11 To: 'XLIFF OMOS TC' < xliff-omos@lists.oasis-open.org > Subject: [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                "urn:oasis:names:tc:xliff:glossary:2.0:glossary": [                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:id": "ge1",                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "Term text",                     "urn:oasis:names:tc:xliff:glossary:2.0:source": "Term source"                   }                 },                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "hot"                   },                   "urn:oasis:names:tc:xliff:glossary:2.0:translations": [                     {                       "urn:oasis:names:tc:xliff:glossary:2.0:text": "hyt",                       "urn:oasis:names:tc:xliff:glossary:2.0:source": "Google"                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 "gls:glossary": [                 {                   "gls:id": "ge1",                   "gls:term": {                     "gls:text": "Term text",                     "gls:source": "Term source"                   }                 },                 {                   "gls:term": {                     "gls:text": "hot"                   },                   "gls:translations": [                     {                       "gls:text": "hyt",                       "gls:source": "Google"                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.      

The more I think about, the more worried I get about working with serialization frameworks if we do some sort of homegrown namespace resolution system. I share your concerns. Also, I believe JSON-LD has disadvantages with respect to serialization frameworks. And introducing our own prefix-URI binding mechanism to define XML-like QNames is not preferable to support existing frameworks. RFC3986 https://tools.ietf.org/html/rfc3986  section 2 says: A URI is composed from a limited set of characters consisting of    digits, letters, and a few graphic symbols.  A reserved subset of    those characters may be used to delimit syntax components within a    URI while the remaining characters, including both the unreserved set    and those reserved characters not acting as delimiters, define each    component's identifying data. Perhaps an ad-hoc name qualification mechanism can be used. Since JSON property names are strings, URIs can be easily embedded without breaking JSON parsers. For example, the space character U+0020 suffices to separate a URI from an unqualified name in a string that contains both: urn:oasis:names:tc:xliff:glossary:2.0:glossary glossary  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^                       URI                         name JSON property names are strings, so this is perfectly valid. Also, using the space character may also be more visually appealing than a character that is graphically rendered such as ^ (hat). I also suspect that spaces are forbidden in JLIFF names, preventing any ambiguity about the placement of the space. Perhaps the downside is that JSON rendition with fully-qualified names is more verbose than XML QNames. I suppose fully-qualified names will not be prevalent in JLIFF so JLIFF fragments do not blow up in size compared to XML, but could be wrong. For hard-code JLIFF serializers, the property names will be a bit more cumbersome to use as a consequence e.g. obj[“URI name”] compared to obj.name (and obj.prefix$name if homegrown prefixes are introduced).   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 May 10, 2017, at 7:47 PM, Chase Tingley < chase@spartansoftwareinc.com > wrote: The more I think about, the more worried I get about working with serialization frameworks if we do some sort of homegrown namespace resolution system. For example, say we take the approach of listing IRIs at the top of the document, so we have something vaguely like: {     prefixes : { gls : urn:oasis:names:tc:xliff:glossary:2.0:glossary },     units : [       {         subunits : [ .... ],         gls:glossary : { ... }       }   ] } But this means that there is no fixed name for the glossary data.  It could be gls:glossary , or my:glossary , or foo:glossary , depending on how the prefix is defined.  How easily can serialization libraries handle this?  The standard approach for most of them is to declare bindings between node names and implementation classes -- but with no fixed name, this doesn't work.  With enough effort, in some libraries It's probably possible to (for example) inject a custom evaluator class into the mapping process to make these decisions on the fly based on what prefixes have been declared, but that's a lot to ask a requirement of a correct implementation.  It may not even be possible in some serialization libraries. On Wed, May 10, 2017 at 6:56 AM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: I really don’t like the idea but for sake of at least investigating the possibility, it is surprising to me that the json serialization library I am using (Newtonsoft) in .NET will read and write the full urn version below.   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: xliff-omos@lists.oasis-open. org [mailto: xliff-omos@lists. oasis-open.org ] On Behalf Of Yves Savourel Sent: 04 May 2017 03:11 To: 'XLIFF OMOS TC' < xliff-omos@lists.oasis-open. org > Subject: [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                 urn:oasis:names: tc:xliff:glossary:2.0: glossary : [                 {                   urn:oasis:names:tc:xliff: glossary:2.0:id : ge1 ,                   urn:oasis:names:tc:xliff: glossary:2.0:term : {                     urn:oasis:names:tc:xliff: glossary:2.0:text : Term text ,                     urn:oasis:names:tc:xliff: glossary:2.0:source : Term source                   }                 },                 {                   urn:oasis:names:tc:xliff: glossary:2.0:term : {                     urn:oasis:names:tc:xliff: glossary:2.0:text : hot                   },                   urn:oasis:names:tc:xliff: glossary:2.0:translations : [                     {                       urn:oasis:names:tc:xliff: glossary:2.0:text : hyt ,                       urn:oasis:names:tc:xliff: glossary:2.0:source : Google                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 gls:glossary : [                 {                   gls:id : ge1 ,                   gls:term : {                     gls:text : Term text ,                     gls:source : Term source                   }                 },                 {                   gls:term : {                     gls:text : hot                   },                   gls:translations : [                     {                       gls:text : hyt ,                       gls:source : Google                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  

Ø   Perhaps the downside is that JSON rendition with fully-qualified names is more verbose than XML QNames. I suppose fully-qualified names will not be prevalent in JLIFF so JLIFF fragments do not blow up in size compared to XML, but could be wrong.   I’m afraid there are quite a few elements/attributes with namespaces in XLIFF. Using the full qualified names would probably be a hindrance in some cases (i.e. _javascript_).   Maybe the prefixes might not be so bad: the prefixes for the modules are pre-defined and reserved, so for a glossary gls_glossary (with _ or whatever separator decided upon) would not be confused with another element in another namespace. Essentially the mapping table would be to get the version of the module. As for extensions, while they are not predictable, we also have to remember that they may be registered too, so they should have some sort of predictability too.   Cheers, -yves   From: Robert van Engelen [mailto:engelen@genivia.com] Sent: Friday, May 12, 2017 9:45 AM To: Chase Tingley <chase@spartansoftwareinc.com> Cc: Phil Ritchie <phil.ritchie@vistatec.com>; Yves Savourel <ysavourel@enlaso.com>; XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] Modules and extensions   The more I think about, the more worried I get about working with serialization frameworks if we do some sort of homegrown namespace resolution system.   I share your concerns. Also, I believe JSON-LD has disadvantages with respect to serialization frameworks. And introducing our own prefix-URI binding mechanism to define XML-like QNames is not preferable to support existing frameworks.   RFC3986 https://tools.ietf.org/html/rfc3986  section 2 says:   "A URI is composed from a limited set of characters consisting of    digits, letters, and a few graphic symbols.  A reserved subset of    those characters may be used to delimit syntax components within a    URI while the remaining characters, including both the unreserved set    and those reserved characters not acting as delimiters, define each    component's identifying data."   Perhaps an ad-hoc name qualification mechanism can be used. Since JSON property names are strings, URIs can be easily embedded without breaking JSON parsers.   For example, the space character U+0020 suffices to separate a URI from an unqualified name in a string that contains both:   "urn:oasis:names:tc:xliff:glossary:2.0:glossary glossary"  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^                       URI                         name   JSON property names are strings, so this is perfectly valid. Also, using the space character may also be more visually appealing than a character that is graphically rendered such as ^ (hat). I also suspect that spaces are forbidden in JLIFF names, preventing any ambiguity about the placement of the space.   Perhaps the downside is that JSON rendition with fully-qualified names is more verbose than XML QNames. I suppose fully-qualified names will not be prevalent in JLIFF so JLIFF fragments do not blow up in size compared to XML, but could be wrong.   For hard-code JLIFF serializers, the property names will be a bit more cumbersome to use as a consequence e.g. obj[“URI name”] compared to obj.name (and obj.prefix$name if homegrown prefixes are introduced).       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 May 10, 2017, at 7:47 PM, Chase Tingley < chase@spartansoftwareinc.com > wrote:   The more I think about, the more worried I get about working with serialization frameworks if we do some sort of homegrown namespace resolution system.   For example, say we take the approach of listing IRIs at the top of the document, so we have something vaguely like:   {    "prefixes": { "gls" : "urn:oasis:names:tc:xliff:glossary:2.0:glossary" },    "units": [       {         "subunits": [ .... ],         "gls:glossary": { ... }       }   ] }   But this means that there is no fixed name for the glossary data.  It could be "gls:glossary", or "my:glossary", or "foo:glossary", depending on how the prefix is defined.  How easily can serialization libraries handle this?  The standard approach for most of them is to declare bindings between node names and implementation classes -- but with no fixed name, this doesn't work.  With enough effort, in some libraries It's probably possible to (for example) inject a custom evaluator class into the mapping process to make these decisions on the fly based on what prefixes have been declared, but that's a lot to ask a requirement of a correct implementation.  It may not even be possible in some serialization libraries.     On Wed, May 10, 2017 at 6:56 AM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   I really don’t like the idea but for sake of at least investigating the possibility, it is surprising to me that the json serialization library I am using (Newtonsoft) in .NET will read and write the full urn version below.   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: xliff-omos@lists.oasis-open.org [mailto: xliff-omos@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: 04 May 2017 03:11 To: 'XLIFF OMOS TC' < xliff-omos@lists.oasis-open.org > Subject: [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                "urn:oasis:names:tc:xliff:glossary:2.0:glossary": [                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:id": "ge1",                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "Term text",                     "urn:oasis:names:tc:xliff:glossary:2.0:source": "Term source"                   }                 },                 {                   "urn:oasis:names:tc:xliff:glossary:2.0:term": {                     "urn:oasis:names:tc:xliff:glossary:2.0:text": "hot"                   },                   "urn:oasis:names:tc:xliff:glossary:2.0:translations": [                     {                       "urn:oasis:names:tc:xliff:glossary:2.0:text": "hyt",                       "urn:oasis:names:tc:xliff:glossary:2.0:source": "Google"                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 "gls:glossary": [                 {                   "gls:id": "ge1",                   "gls:term": {                     "gls:text": "Term text",                     "gls:source": "Term source"                   }                 },                 {                   "gls:term": {                     "gls:text": "hot"                   },                   "gls:translations": [                     {                       "gls:text": "hyt",                       "gls:source": "Google"                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.        

I’m afraid there are quite a few elements/attributes with namespaces in XLIFF. Sure, but what I meant is a bit different: how frequent are JSON properties required to be fully-qualified names? 5%, 10% or 50% of the property names? Only property names associated with modules and extensions are FQnames, I suppose. In other words, how much JSON text would be saved using a mapping table in the JSON doc with the use of prefixes instead of “URI name”? Maybe the prefixes might not be so bad: the prefixes for the modules are pre-defined and reserved, so for a glossary gls_glossary (with _ or whatever separator decided upon) would not be confused with another element in another namespace. Essentially the mapping table would be to get the version of the module. IMHO this still adds the complexity of resolving prefixes with URIs using a mapping table. Implementing a non-standard namespace scope resolution algorithm is undesirable as was pointed out earlier for various reasons Namespaces are pre-defined and reserved (in the proposed/draft standard) as you state, meaning there is no need for an “in-flight JSON mapping table in the JLIFF doc if each namespace has a unique short id such as “gls” that can be used directly with a property name e.g. gls_glossary. The prefix bindings are registered elsewhere (not as tables in the JLIFF doc). As for extensions, while they are not predictable, we also have to remember that they may be registered too, so they should have some sort of predictability too. Perhaps extensions can use FQNames (without a table). JSON APIs can ignore unsupported extensions. Extensions of the form “URI name” are very easy to identify. Summary 1. Modules using unique pre-defined prefixes for property names of the form “prefix_name” with “prefix” registered. The benefit is that “prefix_name” is easy to parse and process by JSON APIs. 2. Non-registered extensions may use unique URIs for property names of the form “URI name”. “URI name” is extensible and the naming is unambiguous (assuming a non-URI separator such as spacing is used).   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 May 21, 2017, at 7:05 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Ø     Perhaps the downside is that JSON rendition with fully-qualified names is more verbose than XML QNames. I suppose fully-qualified names will not be prevalent in JLIFF so JLIFF fragments do not blow up in size compared to XML, but could be wrong.   I’m afraid there are quite a few elements/attributes with namespaces in XLIFF. Using the full qualified names would probably be a hindrance in some cases (i.e. _javascript_).   Maybe the prefixes might not be so bad: the prefixes for the modules are pre-defined and reserved, so for a glossary gls_glossary (with _ or whatever separator decided upon) would not be confused with another element in another namespace. Essentially the mapping table would be to get the version of the module. As for extensions, while they are not predictable, we also have to remember that they may be registered too, so they should have some sort of predictability too.   Cheers, -yves   From:   Robert van Engelen [ mailto:engelen@genivia.com ]   Sent:   Friday, May 12, 2017 9:45 AM To:   Chase Tingley < chase@spartansoftwareinc.com > Cc:   Phil Ritchie < phil.ritchie@vistatec.com >; Yves Savourel < ysavourel@enlaso.com >; XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   Re: [xliff-omos] Modules and extensions   The more I think about, the more worried I get about working with serialization frameworks if we do some sort of homegrown namespace resolution system.   I share your concerns. Also, I believe JSON-LD has disadvantages with respect to serialization frameworks. And introducing our own prefix-URI binding mechanism to define XML-like QNames is not preferable to support existing frameworks.   RFC3986   https://tools.ietf.org/html/rfc3986  section 2 says:   A URI is composed from a limited set of characters consisting of    digits, letters, and a few graphic symbols.  A reserved subset of    those characters may be used to delimit syntax components within a    URI while the remaining characters, including both the unreserved set    and those reserved characters not acting as delimiters, define each    component's identifying data.   Perhaps an ad-hoc name qualification mechanism can be used. Since JSON property names are strings, URIs can be easily embedded without breaking JSON parsers.   For example, the space character U+0020 suffices to separate a URI from an unqualified name in a string that contains both:   urn:oasis:names:tc:xliff:glossary:2.0:glossary glossary  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^                       URI                         name   JSON property names are strings, so this is perfectly valid. Also, using the space character may also be more visually appealing than a character that is graphically rendered such as ^ (hat). I also suspect that spaces are forbidden in JLIFF names, preventing any ambiguity about the placement of the space.   Perhaps the downside is that JSON rendition with fully-qualified names is more verbose than XML QNames. I suppose fully-qualified names will not be prevalent in JLIFF so JLIFF fragments do not blow up in size compared to XML, but could be wrong.   For hard-code JLIFF serializers, the property names will be a bit more cumbersome to use as a consequence e.g.   obj[“URI name”]   compared to   obj.name   (and   obj.prefix$name   if homegrown prefixes are introduced).       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 May 10, 2017, at 7:47 PM, Chase Tingley < chase@spartansoftwareinc.com > wrote:   The more I think about, the more worried I get about working with serialization frameworks if we do some sort of homegrown namespace resolution system.   For example, say we take the approach of listing IRIs at the top of the document, so we have something vaguely like:   {     prefixes : { gls : urn:oasis:names:tc:xliff:glossary:2.0:glossary },     units : [       {         subunits : [ .... ],         gls:glossary : { ... }       }   ] }   But this means that there is no fixed name for the glossary data.  It could be gls:glossary , or my:glossary , or foo:glossary , depending on how the prefix is defined.  How easily can serialization libraries handle this?  The standard approach for most of them is to declare bindings between node names and implementation classes -- but with no fixed name, this doesn't work.  With enough effort, in some libraries It's probably possible to (for example) inject a custom evaluator class into the mapping process to make these decisions on the fly based on what prefixes have been declared, but that's a lot to ask a requirement of a correct implementation.  It may not even be possible in some serialization libraries.     On Wed, May 10, 2017 at 6:56 AM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   I really don’t like the idea but for sake of at least investigating the possibility, it is surprising to me that the json serialization library I am using (Newtonsoft) in .NET will read and write the full urn version below.   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 <image001.jpg> Think Global <image002.jpg> <image002.jpg> <image002.jpg> <image002.jpg>   From:   xliff-omos@lists.oasis-open.org   [mailto: xliff-omos@lists.oasis-open.org ]   On Behalf Of   Yves Savourel Sent:   04 May 2017 03:11 To:   'XLIFF OMOS TC' < xliff-omos@lists.oasis-open.org > Subject:   [xliff-omos] Modules and extensions   Hi all,   Implementing the Glossary module for JLIFF made me wonder about how we can have a common representation of modules (and extensions). Some implementations will not support a module like Glossary, but they still have to read JLIFF input that will have glossary entries. How can we accommodate both?   Maybe we need to have the namespace identifier for the module/extension with the name, so we would have:                 urn:oasis:names:tc:xliff:glossary:2.0:glossary : [                 {                   urn:oasis:names:tc:xliff:glossary:2.0:id : ge1 ,                   urn:oasis:names:tc:xliff:glossary:2.0:term : {                     urn:oasis:names:tc:xliff:glossary:2.0:text : Term text ,                     urn:oasis:names:tc:xliff:glossary:2.0:source : Term source                   }                 },                 {                   urn:oasis:names:tc:xliff:glossary:2.0:term : {                     urn:oasis:names:tc:xliff:glossary:2.0:text : hot                   },                   urn:oasis:names:tc:xliff:glossary:2.0:translations : [                     {                       urn:oasis:names:tc:xliff:glossary:2.0:text : hyt ,                       urn:oasis:names:tc:xliff:glossary:2.0:source : Google                     }                   ]                 }               ]   Certainly not great. Another way could be to use the prefixes:                 gls:glossary : [                 {                   gls:id : ge1 ,                   gls:term : {                     gls:text : Term text ,                     gls:source : Term source                   }                 },                 {                   gls:term : {                     gls:text : hot                   },                   gls:translations : [                     {                       gls:text : hyt ,                       gls:source : Google                     }                   ]                 }               ]   With somewhere in the JLIFF input a map of the namespace identifiers and their prefixes. It’d be better, but still not great. For example I’m not sure what the ‘:’ in the names would do in _javascript_. And I’m not sure having to lookup prefixes will be very easy.   Thoughts?   Thanks, -yves   Yves Savourel Localization Solutions Architect     ENLASO ® 4888 Pearl East Circle     Suite 300E     Boulder     Colorado 80301 t:   303.945.3759     f:   303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice   The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.

Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log(x.name$b); à ok   var x = {"name.b": "text"}; console.log(x.name.b); à error   More tests are probably needed.   cheers, -yves

I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names. Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is hard-coded and so is console.log(x[“name.b”])  also hard-coded, but with a period in the property name that requires quotes). - Robert   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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = { name$b : text }; console.log(x.name$b);   à   ok   var x = { name.b : text }; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves

Hi Robert, all,   Ø   I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø   Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From: Robert van Engelen [mailto:engelen@genivia.com] Sent: Tuesday, May 23, 2017 11:11 AM To: Yves Savourel <ysavourel@enlaso.com> Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”])  also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log(x.name$b);   à   ok   var x = {"name.b": "text"}; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves  

Hi Yves, all, previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two cent ... (I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach) - Felix  2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com > : Hi Robert, all,   Ø   I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø   Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From: Robert van Engelen [mailto: engelen@genivia.com ] Sent: Tuesday, May 23, 2017 11:11 AM To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject: Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”])  also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log( x.name $b);   à   ok   var x = {"name.b": "text"}; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves  

Felix
 
I think one of the main concerns/unknowns with json-ld was that it couldn’t model the complexities of jliff. For example, more than one ‘active’ namespace within
the same ‘element’ scope.
 
Despite FREME I couldn’t answer that question. Perhaps you can. My recollection is that json-ld namespaces are defined at the ‘head’ of a section and applies to
everything within that level of hierarchy: e.g. @context in FREME.
 
Phil
 







From: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org]
On Behalf Of Felix Sasaki
Sent: 25 May 2017 07:55
To: Yves Savourel <ysavourel@enlaso.com>
Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org>
Subject: Re: [xliff-omos] Modules and extensions


 


Hi Yves, all,


 


previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two
cent ...


 


(I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)


 


- Felix 


 



 

2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com >:



Hi Robert, all,
 
Ø  
I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.
 
A ‘_’ would be fine with me.
I was just under the impression ‘$’ was the preference for you (and maybe others).
I just wanted to be sure it would work with _javascript_.
 
Ø  
Other programming languages may not accept $ in hard-coded property/variable names…
 
Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some
kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default
automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.
 
Cheers,
-yves
 

 



From: Robert van Engelen [mailto: engelen@genivia.com ]

Sent: Tuesday, May 23, 2017 11:11 AM
To: Yves Savourel < ysavourel@enlaso.com >
Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open.org >
Subject: Re: [xliff-omos] Modules and extensions


 

 

I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported
in variable names.




 


Other programming languages may not accept $ in hard-coded property/variable names (i.e.
console.log(x.name.b) is "hard-coded" and so is
console.log(x[“name.b”])  also hard-coded, but with a period in the property name that requires quotes).


 


- Robert


 

 


  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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:

 


Regarding separator, from quick tests:


 


Dollar-sign would work, but not period, IMO:


 


var x = {"name$b": "text"};


console.log( x.name $b);   à   ok


 


var x = {"name.b": "text"};


console.log(x.name.b);   à   error


 


More tests are probably needed.


 


cheers,


-yves




 









 

Thanks for the reminder Felix. Like Phil, I’m just wondering about the cost of JSON-LD when various namespaces are mixed in the same object. Looking at examples such as those here: https://json-ld.org/spec/latest/json-ld-api-best-practices/#dfn-json-ld-context , the resolution of the namespaces seems relatively complicated and changes the object structure. But I’m probably missing a lot.   Cheers, -yves   Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: Felix Sasaki [mailto:felix@sasakiatcf.com] Sent: Thursday, May 25, 2017 12:55 AM To: Yves Savourel <ysavourel@enlaso.com> Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] Modules and extensions   Hi Yves, all,   previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two cent ...   (I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)   - Felix      2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com >: Hi Robert, all,   Ø   I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø   Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From: Robert van Engelen [mailto: engelen@genivia.com ] Sent: Tuesday, May 23, 2017 11:11 AM To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject: Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”]) also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log( x.name $b);   à   ok   var x = {"name.b": "text"}; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves    

Hi Yves and Phil, json-ld does not have the notion of namespaces, see the json-ld spec http://www.w3.org/TR/json-ld/ the term namespace appears just one time. Rather, json-ld provides means to express URIs in a compact form, see http://www.w3.org/TR/json-ld/#compact-iris But the full form are still URIs. E.g. in example 20 in the json-ld spec,  foaf:name is a short form for  http://xmlns.com/foaf/0.1/name I do not understand the full requirements for separating XLIFF sub vocabularies (to use a neutral term). But no need to discuss this further here. I will look at the thread and see if I can come up with a json-ld example later. Cheers, Felix 2017-05-25 14:27 GMT+02:00 Yves Savourel < ysavourel@enlaso.com > : Thanks for the reminder Felix. Like Phil, I’m just wondering about the cost of JSON-LD when various namespaces are mixed in the same object. Looking at examples such as those here: https://json-ld.org/spec/ latest/json-ld-api-best- practices/#dfn-json-ld-context , the resolution of the namespaces seems relatively complicated and changes the object structure. But I’m probably missing a lot.   Cheers, -yves   Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: Felix Sasaki [mailto: felix@sasakiatcf.com ] Sent: Thursday, May 25, 2017 12:55 AM To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject: Re: [xliff-omos] Modules and extensions   Hi Yves, all,   previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two cent ...   (I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)   - Felix      2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com >: Hi Robert, all,   Ø   I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø   Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From: Robert van Engelen [mailto: engelen@genivia.com ] Sent: Tuesday, May 23, 2017 11:11 AM To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject: Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”]) also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log( x.name $b);   à   ok   var x = {"name.b": "text"}; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves    

Yves, Chase, Felix, David and other TC members, I have made the changes to the JLIFF draft schema 0.9.4 and the three examples, as we discussed in the meeting last week. Let me know if this looks OK. I am working on examples of extensions based on JSON-LD. Thanks.   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 May 25, 2017, at 8:27 AM, Yves Savourel < ysavourel@enlaso.com > wrote: Thanks for the reminder Felix. Like Phil, I’m just wondering about the cost of JSON-LD when various namespaces are mixed in the same object. Looking at examples such as those here:   https://json-ld.org/spec/latest/json-ld-api-best-practices/#dfn-json-ld-context , the resolution of the namespaces seems relatively complicated and changes the object structure. But I’m probably missing a lot.   Cheers, -yves   Yves Savourel   Localization Solutions Architect     t:   303.951.4523     f:   303.516.1701     ENLASO ®   From:   Felix Sasaki [ mailto:felix@sasakiatcf.com ]   Sent:   Thursday, May 25, 2017 12:55 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   Re: [xliff-omos] Modules and extensions   Hi Yves, all,   previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two cent ...   (I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)   - Felix      2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com >: Hi Robert, all,   Ø     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø     Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From:   Robert van Engelen [mailto: engelen@genivia.com ]   Sent:   Tuesday, May 23, 2017 11:11 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is hard-coded and so is console.log(x[“name.b”]) also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = { name$b : text }; console.log( x.name $b);   à   ok   var x = { name.b : text }; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves

In 0.9.4 the text property of the element-xx objects has been removed. It made serialization nice and easy and simplified the model. Was it deemed unnecessary?       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: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Robert van Engelen Sent: 20 June 2017 19:18 To: Yves Savourel <ysavourel@enlaso.com> Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] Modules and extensions     Yves, Chase, Felix, David and other TC members,   I have made the changes to the JLIFF draft schema 0.9.4 and the three examples, as we discussed in the meeting last week. Let me know if this looks OK.   I am working on examples of extensions based on JSON-LD.   Thanks.     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 May 25, 2017, at 8:27 AM, Yves Savourel < ysavourel@enlaso.com > wrote:   Thanks for the reminder Felix. Like Phil, I’m just wondering about the cost of JSON-LD when various namespaces are mixed in the same object. Looking at examples such as those here:   https://json-ld.org/spec/latest/json-ld-api-best-practices/#dfn-json-ld-context , the resolution of the namespaces seems relatively complicated and changes the object structure. But I’m probably missing a lot.   Cheers, -yves   Yves Savourel   Localization Solutions Architect     t:   303.951.4523     f:   303.516.1701     ENLASO ®   From:   Felix Sasaki [ mailto:felix@sasakiatcf.com ]   Sent:   Thursday, May 25, 2017 12:55 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   Re: [xliff-omos] Modules and extensions   Hi Yves, all,   previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two cent ...   (I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)   - Felix      2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com >: Hi Robert, all,   Ø     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø     Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From:   Robert van Engelen [mailto: engelen@genivia.com ]   Sent:   Tuesday, May 23, 2017 11:11 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”]) also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log( x.name $b);   à   ok   var x = {"name.b": "text"}; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves  

All   Sorry ignore me, it’s been a long day. We have the text-element so everything makes sense.   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: xliff-omos@lists.oasis-open.org [mailto:xliff-omos@lists.oasis-open.org] On Behalf Of Phil Ritchie Sent: 27 June 2017 17:55 To: Robert van Engelen <engelen@genivia.com>; Yves Savourel <ysavourel@enlaso.com> Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: RE: [xliff-omos] Modules and extensions     In 0.9.4 the text property of the element-xx objects has been removed. It made serialization nice and easy and simplified the model. Was it deemed unnecessary?         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: xliff-omos@lists.oasis-open.org [ mailto:xliff-omos@lists.oasis-open.org ] On Behalf Of Robert van Engelen Sent: 20 June 2017 19:18 To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject: Re: [xliff-omos] Modules and extensions     Yves, Chase, Felix, David and other TC members,   I have made the changes to the JLIFF draft schema 0.9.4 and the three examples, as we discussed in the meeting last week. Let me know if this looks OK.   I am working on examples of extensions based on JSON-LD.   Thanks.     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 May 25, 2017, at 8:27 AM, Yves Savourel < ysavourel@enlaso.com > wrote:   Thanks for the reminder Felix. Like Phil, I’m just wondering about the cost of JSON-LD when various namespaces are mixed in the same object. Looking at examples such as those here:   https://json-ld.org/spec/latest/json-ld-api-best-practices/#dfn-json-ld-context , the resolution of the namespaces seems relatively complicated and changes the object structure. But I’m probably missing a lot.   Cheers, -yves   Yves Savourel   Localization Solutions Architect     t:   303.951.4523     f:   303.516.1701     ENLASO ®   From:   Felix Sasaki [ mailto:felix@sasakiatcf.com ]   Sent:   Thursday, May 25, 2017 12:55 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   Re: [xliff-omos] Modules and extensions   Hi Yves, all,   previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two cent ...   (I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)   - Felix      2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com >: Hi Robert, all,   Ø     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø     Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From:   Robert van Engelen [mailto: engelen@genivia.com ]   Sent:   Tuesday, May 23, 2017 11:11 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”]) also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log( x.name $b);   à   ok   var x = {"name.b": "text"}; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves    

Hi, The JLIFF schema 0.9.4 is updated on GitHub. Added are the `srcDir` and `trgDir` properties to the JSON JLIFF “wrapper” object, each with `ltr`, `rtl`, or `auto` enumerated string values. I’ve restructured the JLIFF object schema by providing a choice of `files`, `fragment`, `groups`, `units`, and `subunits` properties. I’ve tested the changes with schema validators and examples. These (unofficial) tests passed. See the modified `jliff` object type in the schema somewhere defined at the top. - Robert

All   I’ve been looking at this a little this morning and the ability to wrap the choice of ‘files’, ‘fragment’, ‘groups’, ‘units’ and ‘subunits’ introduces a lot of complexity into code both during serialization/deserialization and also utility methods such as something which would GetAllSegments().   From what I can see the anonymous wrapper object (named ‘jliff’ in my library) would need a ‘content’ or ‘body’ property which stores instances of an interface which ‘files’, ‘units’, ‘subunits’, etc. would conform to. This is fine but I think then each of these possible contents would need a ‘type’ property so that my serialization library can figure out what concrete type to instantiate during deserialization.   I’ll play with it a little more to see if I can refine it a bit.   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: Tuesday 25 July 2017 19:40 To: Phil Ritchie <phil.ritchie@vistatec.com>; Yves Savourel <ysavourel@enlaso.com>; Chase Tingley <chase@spartansoftwareinc.com>; David Filip <david.filip@adaptcentre.ie> Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: JLIFF files, fragment, groups, units, subunits     Hi,   The JLIFF schema 0.9.4 is updated on GitHub.   Added are the `srcDir` and `trgDir` properties to the JSON JLIFF “wrapper” object, each with `ltr`, `rtl`, or `auto` enumerated string values.   I’ve restructured the JLIFF object schema by providing a choice of `files`, `fragment`, `groups`, `units`, and `subunits` properties.   I’ve tested the changes with schema validators and examples. These (unofficial) tests passed.   See the modified `jliff` object type in the schema somewhere defined at the top.   - Robert  

I worry about these issues: 1. Interoperability with XLIFF - e.g. XLIFF expects a top-level structure, what processing steps are needed when only “subunits” are provided? 2. Model inconsistencies - e.g. “subunits” at the top-level strips the required “id” from “files” and “units”, what are the semantics implications? 3. Practical use issues - e.g. more complex code and semantics to consume JLIFF. With respect to #2, consider the following example: {      jliff : “1.1 ,      srcLang : en ,      trgLang : fr ,      files : [         {              id : fl ,              units : [                 {                      id : u1 ,                     },                      subunits : [ Which has the required “id” property on fragment (array element of “files”), and required “id” property on “unit” (array element of “units”). Permitting “subunits” as a root level property effectively strips the required “id” from fragment and unit since this no longer represents a full fragment: {      jliff : “1.1 ,      srcLang : en ,      trgLang : fr ,       subunits : [ The question is whether the two representations given above are considered semantically identical or not, or semantically close. If they are semantically identical then the “id” properties must be made optional in the full fragment representation, since the second representation omits them. If they are not semantically identical, then the semantics will need to be defined very precisely to avoid an “id” omission loophole, to put it that way. - Robert   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 Jul 26, 2017, at 8:02 AM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: All   I’ve been looking at this a little this morning and the ability to wrap the choice of ‘files’, ‘fragment’, ‘groups’, ‘units’ and ‘subunits’ introduces a lot of complexity into code both during serialization/deserialization and also utility methods such as something which would GetAllSegments().   From what I can see the anonymous wrapper object (named ‘jliff’ in my library) would need a ‘content’ or ‘body’ property which stores instances of an interface which ‘files’, ‘units’, ‘subunits’, etc. would conform to. This is fine but I think then each of these possible contents would need a ‘type’ property so that my serialization library can figure out what concrete type to instantiate during deserialization.   I’ll play with it a little more to see if I can refine it a bit.   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:   Tuesday 25 July 2017 19:40 To:   Phil Ritchie < phil.ritchie@vistatec.com >; Yves Savourel < ysavourel@enlaso.com >; Chase Tingley < chase@spartansoftwareinc.com >; David Filip < david.filip@adaptcentre.ie > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   JLIFF files, fragment, groups, units, subunits     Hi,   The JLIFF schema 0.9.4 is updated on GitHub.   Added are the `srcDir` and `trgDir` properties to the JSON JLIFF “wrapper” object, each with `ltr`, `rtl`, or `auto` enumerated string values.   I’ve restructured the JLIFF object schema by providing a choice of `files`, `fragment`, `groups`, `units`, and `subunits` properties.   I’ve tested the changes with schema validators and examples. These (unofficial) tests passed.   See the modified `jliff` object type in the schema somewhere defined at the top.   - Robert

All   My second attempt today (with an object hierarchy and generics) is a little more intuitive and refined. I’ll try and get a couple of examples finished and then we can discuss the trade-offs.   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: Wednesday 26 July 2017 13:40 To: Phil Ritchie <phil.ritchie@vistatec.com> Cc: Yves Savourel <ysavourel@enlaso.com>; Chase Tingley <chase@spartansoftwareinc.com>; David Filip <david.filip@adaptcentre.ie>; XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] JLIFF files, fragment, groups, units, subunits     I worry about these issues:   1. Interoperability with XLIFF - e.g. XLIFF expects a top-level structure, what processing steps are needed when only “subunits” are provided?   2. Model inconsistencies - e.g. “subunits” at the top-level strips the required “id” from “files” and “units”, what are the semantics implications?   3. Practical use issues - e.g. more complex code and semantics to consume JLIFF.   With respect to #2, consider the following example:   {     "jliff": “1.1",     "srcLang": "en",     "trgLang": "fr",     "files": [         {             "id": "fl",             "units": [                 {                     "id": "u1",                     },                     "subunits": [   Which has the required “id” property on fragment (array element of “files”), and required “id” property on “unit” (array element of “units”). Permitting “subunits” as a root level property effectively strips the required “id” from fragment and unit since this no longer represents a full fragment:   {     "jliff": “1.1",     "srcLang": "en",     "trgLang": "fr",      "subunits": [   The question is whether the two representations given above are considered semantically identical or not, or semantically close. If they are semantically identical then the “id” properties must be made optional in the full fragment representation, since the second representation omits them. If they are not semantically identical, then the semantics will need to be defined very precisely to avoid an “id” omission loophole, to put it that way.   - Robert       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 Jul 26, 2017, at 8:02 AM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   All   I’ve been looking at this a little this morning and the ability to wrap the choice of ‘files’, ‘fragment’, ‘groups’, ‘units’ and ‘subunits’ introduces a lot of complexity into code both during serialization/deserialization and also utility methods such as something which would GetAllSegments().   From what I can see the anonymous wrapper object (named ‘jliff’ in my library) would need a ‘content’ or ‘body’ property which stores instances of an interface which ‘files’, ‘units’, ‘subunits’, etc. would conform to. This is fine but I think then each of these possible contents would need a ‘type’ property so that my serialization library can figure out what concrete type to instantiate during deserialization.   I’ll play with it a little more to see if I can refine it a bit.   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:   Tuesday 25 July 2017 19:40 To:   Phil Ritchie < phil.ritchie@vistatec.com >; Yves Savourel < ysavourel@enlaso.com >; Chase Tingley < chase@spartansoftwareinc.com >; David Filip < david.filip@adaptcentre.ie > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   JLIFF files, fragment, groups, units, subunits     Hi,   The JLIFF schema 0.9.4 is updated on GitHub.   Added are the `srcDir` and `trgDir` properties to the JSON JLIFF “wrapper” object, each with `ltr`, `rtl`, or `auto` enumerated string values.   I’ve restructured the JLIFF object schema by providing a choice of `files`, `fragment`, `groups`, `units`, and `subunits` properties.   I’ve tested the changes with schema validators and examples. These (unofficial) tests passed.   See the modified `jliff` object type in the schema somewhere defined at the top.   - Robert  

All   I came up with two approaches and I’m sure there could be more. They do not suffer from many of the complexities expressed in my start of this thread (thank goodness). Apologies if implementation of the standard is not your thing, I find that sometimes it teases out issues.   The first uses an object hierarchy: JliffBase <- JliffOfSubUnits, JliffOfUnits, JliffOfFiles, etc.   The second uses generics: Jliff<ISubUnit>, Jliff<File>, Jliff<IUnit>, etc. This does mean that this implementation has a single property called “content” rather than “units”, “files”, “groups”, etc.   In both cases the de-serialization has to do a bit of work reflecting what concrete types the interfaces are holding.   I have to re-work some of my utility methods but they were probably of a bad design in the first place in hindsight.   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: Wednesday 26 July 2017 13:40 To: Phil Ritchie <phil.ritchie@vistatec.com> Cc: Yves Savourel <ysavourel@enlaso.com>; Chase Tingley <chase@spartansoftwareinc.com>; David Filip <david.filip@adaptcentre.ie>; XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] JLIFF files, fragment, groups, units, subunits     I worry about these issues:   1. Interoperability with XLIFF - e.g. XLIFF expects a top-level structure, what processing steps are needed when only “subunits” are provided?   2. Model inconsistencies - e.g. “subunits” at the top-level strips the required “id” from “files” and “units”, what are the semantics implications?   3. Practical use issues - e.g. more complex code and semantics to consume JLIFF.   With respect to #2, consider the following example:   {     "jliff": “1.1",     "srcLang": "en",     "trgLang": "fr",     "files": [         {             "id": "fl",             "units": [                 {                     "id": "u1",                     },                     "subunits": [   Which has the required “id” property on fragment (array element of “files”), and required “id” property on “unit” (array element of “units”). Permitting “subunits” as a root level property effectively strips the required “id” from fragment and unit since this no longer represents a full fragment:   {     "jliff": “1.1",     "srcLang": "en",     "trgLang": "fr",      "subunits": [   The question is whether the two representations given above are considered semantically identical or not, or semantically close. If they are semantically identical then the “id” properties must be made optional in the full fragment representation, since the second representation omits them. If they are not semantically identical, then the semantics will need to be defined very precisely to avoid an “id” omission loophole, to put it that way.   - Robert       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 Jul 26, 2017, at 8:02 AM, Phil Ritchie < phil.ritchie@vistatec.com > wrote:   All   I’ve been looking at this a little this morning and the ability to wrap the choice of ‘files’, ‘fragment’, ‘groups’, ‘units’ and ‘subunits’ introduces a lot of complexity into code both during serialization/deserialization and also utility methods such as something which would GetAllSegments().   From what I can see the anonymous wrapper object (named ‘jliff’ in my library) would need a ‘content’ or ‘body’ property which stores instances of an interface which ‘files’, ‘units’, ‘subunits’, etc. would conform to. This is fine but I think then each of these possible contents would need a ‘type’ property so that my serialization library can figure out what concrete type to instantiate during deserialization.   I’ll play with it a little more to see if I can refine it a bit.   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:   Tuesday 25 July 2017 19:40 To:   Phil Ritchie < phil.ritchie@vistatec.com >; Yves Savourel < ysavourel@enlaso.com >; Chase Tingley < chase@spartansoftwareinc.com >; David Filip < david.filip@adaptcentre.ie > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject:   JLIFF files, fragment, groups, units, subunits     Hi,   The JLIFF schema 0.9.4 is updated on GitHub.   Added are the `srcDir` and `trgDir` properties to the JSON JLIFF “wrapper” object, each with `ltr`, `rtl`, or `auto` enumerated string values.   I’ve restructured the JLIFF object schema by providing a choice of `files`, `fragment`, `groups`, `units`, and `subunits` properties.   I’ve tested the changes with schema validators and examples. These (unofficial) tests passed.   See the modified `jliff` object type in the schema somewhere defined at the top.   - Robert  

Hi all, Picking this thread up after a long while.  I've also been looking at JSON-LD more closely.  I am coming around to the idea that others have suggested that the @Context mechanism deserves more attention as a possible way forward on modules and namespaces. One key observation about  @Context  is that it's not really a method for handling namespace prefixes.  Instead, it maps terms to IRIs.  But since most modules are relatively limited in the number of elements they use, @Context could simply predefine them.  For example, the glossary module could be predefined like this: {   "@context": {     "gl_glossary": "urn:oasis:names:tc:xliff:glossary:2.0:glossary:glossary",     "gl_glossEntry": "urn:oasis:names:tc:xliff:glossary:2.0:glossary:glossEntry",     "gl_term": "urn:oasis:names:tc:xliff:glossary:2.0:glossary:term",      "gl_translation": "urn:oasis:names:tc:xliff:glossary:2.0:glossary:translation",     "gl_definition": "urn:oasis:names:tc:xliff:glossary:2.0:glossary:definition"   } } This would map the official URIs for the XLIFF 2.x concepts to JSON terms using a standard prefix (in my example, "gl_").  This example only covers glossary, but it would be easy to build a context block for all of the core elements (for completeness) as well as the elements in the standard modules.  This would be a meaty block of JSON-LD, but it can be included by @context reference at top of the JLIFF document from a standard location, or even included via Link HTTP header .  The @context declaration could also serve as a de facto type statement for the document, if the existing "jliff" element was now felt to be rendant.  For example, assuming a hypotehtical jsonld document produced by this TC: {   "@context": " http://docs.oasis-open.org/xliff-omos/jliff/v2.1/jliff-v2.1.jsonld ",   "srcLang": "en",   "tgtLang": "fr",   .... } Since multiple contexts can be declared in a document , 3rd party modules could be supported via additional @context declarations (although this may need more thought). This is less flexible than the XML namespace prefixing system, since it doesn't allow you to remap the namespace to a different prefix.  However, it would let us lock down the use of particular JSON term names in a standardized way. This doesn't resolve the other question of a namespace prefix character.  I've used '_' above, which I've said on calls I don't like.  It would feel nicer to be able to use "gl:term", but as has been pointed out, this makes the JSON a problem to manipulate in _javascript_, which surely must be an important use case. ct On Tue, Jun 27, 2017 at 12:27 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: All   Sorry ignore me, it’s been a long day. We have the text-element so everything makes sense.   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: xliff-omos@lists.oasis-open. org [mailto: xliff-omos@lists. oasis-open.org ] On Behalf Of Phil Ritchie Sent: 27 June 2017 17:55 To: Robert van Engelen < engelen@genivia.com >; Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject: RE: [xliff-omos] Modules and extensions     In 0.9.4 the text property of the element-xx objects has been removed. It made serialization nice and easy and simplified the model. Was it deemed unnecessary?         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: xliff-omos@lists.oasis-open. org [ mailto:xliff-omos@lists. oasis-open.org ] On Behalf Of Robert van Engelen Sent: 20 June 2017 19:18 To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject: Re: [xliff-omos] Modules and extensions     Yves, Chase, Felix, David and other TC members,   I have made the changes to the JLIFF draft schema 0.9.4 and the three examples, as we discussed in the meeting last week. Let me know if this looks OK.   I am working on examples of extensions based on JSON-LD.   Thanks.     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 May 25, 2017, at 8:27 AM, Yves Savourel < ysavourel@enlaso.com > wrote:   Thanks for the reminder Felix. Like Phil, I’m just wondering about the cost of JSON-LD when various namespaces are mixed in the same object. Looking at examples such as those here:   https://json-ld.org/ spec/latest/json-ld-api-best- practices/#dfn-json-ld-context , the resolution of the namespaces seems relatively complicated and changes the object structure. But I’m probably missing a lot.   Cheers, -yves   Yves Savourel   Localization Solutions Architect     t:   303.951.4523     f:   303.516.1701     ENLASO ®   From:   Felix Sasaki [ mailto:felix@sasakiatcf.com ]   Sent:   Thursday, May 25, 2017 12:55 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject:   Re: [xliff-omos] Modules and extensions   Hi Yves, all,   previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two cent ...   (I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)   - Felix      2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com >: Hi Robert, all,   Ø     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø     Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From:   Robert van Engelen [mailto: engelen@genivia.com ]   Sent:   Tuesday, May 23, 2017 11:11 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject:   Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”]) also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log( x.name $b);   à   ok   var x = {"name.b": "text"}; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves    

Hi all, … I am coming around to the idea that others have suggested that the @Context mechanism deserves more attention as a possible way forward on modules and namespaces. Agreed. This is less flexible than the XML namespace prefixing system, since it doesn't allow you to remap the namespace to a different prefix.  However, it would let us lock down the use of particular JSON term names in a standardized way. I believe compact IRIs  https://json-ld.org/spec/latest/json-ld/#compact-iris  provide a mapping for IRIs to prefixes, by using @context to hold prefix-IRI bindings. For example, given the context {   @context : {     gl : urn:oasis:names:tc:xliff:glossary:2.0:glossary   } } a prefixed name “gl:glossary” in the corpus means urn:oasis:names:tc:xliff:glossary:2.0:glossary:glossary” as per JSON-LD semantics. In other words, JSON-LD normalizes “gl:glossary” into an expanded form with the URI and without the “gl” prefix. This means that we do not need to lock down a specific prefix as any prefix defined in the @context will do. This looks a pretty simple approach if we want to go that route. JSON-LD seems to follow document-oriented concepts found in XML, which is good because it supports XLIFF-JLIFF compatibility with respect to modules and extensions. Thinking XML prefixes simply translate to JSON-LD @context entries and back. So we’re coming back to the discussion of colons in names, which JSON-LD supports. We can’t escape that if we use parts of JSON-LD, because of the inherent JSON-LD semantics and uses of colons. It would feel nicer to be able to use gl:term , but as has been pointed out, this makes the JSON a problem to manipulate in _javascript_, which surely must be an important use case. This should not be a problem in _javascript_ or in any other PL or JSON API, because we simply use properties by string instead of by name in _javascript_ such as object[ urn:oasis:names:tc:xliff:glossary:2.0:glossary:glossary”], after “gl:glossary” is normalized to urn:oasis:names:tc:xliff:glossary:2.0:glossary:glossary” in the JSON corpus. Some pre-processing is needed for the normalization by a library (off the shelf?), but this is not too steep a price to pay to use JSON-LD contexts IMO.   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 7, 2017, at 3:05 PM, Chase Tingley < chase@spartansoftwareinc.com > wrote: Hi all, Picking this thread up after a long while.  I've also been looking at JSON-LD more closely.  I am coming around to the idea that others have suggested that the @Context mechanism deserves more attention as a possible way forward on modules and namespaces. One key observation about  @Context  is that it's not really a method for handling namespace prefixes.  Instead, it maps terms to IRIs.  But since most modules are relatively limited in the number of elements they use, @Context could simply predefine them.  For example, the glossary module could be predefined like this: {   @context : {     gl_glossary : urn:oasis:names:tc:xliff:glossary:2.0:glossary:glossary ,     gl_glossEntry : urn:oasis:names:tc:xliff:glossary:2.0:glossary:glossEntry ,     gl_term : urn:oasis:names:tc:xliff:glossary:2.0:glossary:term ,      gl_translation : urn:oasis:names:tc:xliff:glossary:2.0:glossary:translation ,     gl_definition : urn:oasis:names:tc:xliff:glossary:2.0:glossary:definition   } } This would map the official URIs for the XLIFF 2.x concepts to JSON terms using a standard prefix (in my example, gl_ ).  This example only covers glossary, but it would be easy to build a context block for all of the core elements (for completeness) as well as the elements in the standard modules.  This would be a meaty block of JSON-LD, but it can be included by @context reference at top of the JLIFF document from a standard location, or even included via Link HTTP header .  The @context declaration could also serve as a de facto type statement for the document, if the existing jliff element was now felt to be rendant.  For example, assuming a hypotehtical jsonld document produced by this TC: {   @context : http://docs.oasis-open.org/xliff-omos/jliff/v2.1/jliff-v2.1.jsonld ,   srcLang : en ,   tgtLang : fr ,   .... } Since multiple contexts can be declared in a document , 3rd party modules could be supported via additional @context declarations (although this may need more thought). This is less flexible than the XML namespace prefixing system, since it doesn't allow you to remap the namespace to a different prefix.  However, it would let us lock down the use of particular JSON term names in a standardized way. This doesn't resolve the other question of a namespace prefix character.  I've used '_' above, which I've said on calls I don't like.  It would feel nicer to be able to use gl:term , but as has been pointed out, this makes the JSON a problem to manipulate in _javascript_, which surely must be an important use case. ct On Tue, Jun 27, 2017 at 12:27 PM, Phil Ritchie < phil.ritchie@vistatec.com > wrote: All   Sorry ignore me, it’s been a long day. We have the text-element so everything makes sense.   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: xliff-omos@lists.oasis-open. org [mailto: xliff-omos@lists. oasis-open.org ] On Behalf Of Phil Ritchie Sent: 27 June 2017 17:55 To: Robert van Engelen < engelen@genivia.com >; Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject: RE: [xliff-omos] Modules and extensions     In 0.9.4 the text property of the element-xx objects has been removed. It made serialization nice and easy and simplified the model. Was it deemed unnecessary?         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: xliff-omos@lists.oasis-open. org [ mailto:xliff-omos@lists. oasis-open.org ] On Behalf Of Robert van Engelen Sent: 20 June 2017 19:18 To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject: Re: [xliff-omos] Modules and extensions     Yves, Chase, Felix, David and other TC members,   I have made the changes to the JLIFF draft schema 0.9.4 and the three examples, as we discussed in the meeting last week. Let me know if this looks OK.   I am working on examples of extensions based on JSON-LD.   Thanks.     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 May 25, 2017, at 8:27 AM, Yves Savourel < ysavourel@enlaso.com > wrote:   Thanks for the reminder Felix. Like Phil, I’m just wondering about the cost of JSON-LD when various namespaces are mixed in the same object. Looking at examples such as those here:   https://json-ld.org/ spec/latest/json-ld-api-best- practices/#dfn-json-ld-context , the resolution of the namespaces seems relatively complicated and changes the object structure. But I’m probably missing a lot.   Cheers, -yves   Yves Savourel   Localization Solutions Architect     t:   303.951.4523     f:   303.516.1701     ENLASO ®   From:   Felix Sasaki [ mailto:felix@sasakiatcf.com ]   Sent:   Thursday, May 25, 2017 12:55 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject:   Re: [xliff-omos] Modules and extensions   Hi Yves, all,   previously in this thread people said they are worried about ad hoc created namespace resolution systems. I understand the worry about json-ld complexity, but at least it is a standard solution, with many libraries available. Just my two cent ...   (I understand that it is likely that people won't go the json-ld path, this is just my last attempt to mention this approach)   - Felix      2017-05-25 4:28 GMT+02:00 Yves Savourel < ysavourel@enlaso.com >: Hi Robert, all,   Ø     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   A ‘_’ would be fine with me. I was just under the impression ‘$’ was the preference for you (and maybe others). I just wanted to be sure it would work with _javascript_.   Ø     Other programming languages may not accept $ in hard-coded property/variable names…   Quite right. But I wonder if it matters: Languages other than _javascript_ are likely to go through some kind of marshalling of the JSON data into their own data structures and have ways to address such issue. Actually _javascript_ is probably a special case: the more I work on JLIFF, the more I think it’d be quite hard for most languages to just rely on default automated mapping mechanism to get the proper input/output. But hopefully I’m wrong.   Cheers, -yves     From:   Robert van Engelen [mailto: engelen@genivia.com ]   Sent:   Tuesday, May 23, 2017 11:11 AM To:   Yves Savourel < ysavourel@enlaso.com > Cc:   XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject:   Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is hard-coded and so is console.log(x[“name.b”]) also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = { name$b : text }; console.log( x.name $b);   à   ok   var x = { name.b : text }; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves    

Hi Robert, On Tue, Oct 10, 2017 at 6:50 AM, Robert van Engelen < engelen@genivia.com > wrote: I believe compact IRIs  https://json-ld.org/spec/ latest/json-ld/#compact-iris  p rovide a mapping for IRIs to prefixes, by using @context to hold prefix-IRI bindings. For example, given the context {   "@context": {     "gl": "urn:oasis:names:tc:xliff:glos sary:2.0:glossary"   } } a prefixed name “gl:glossary” in the corpus means "urn:oasis:names:tc:xliff:glos sary:2.0:glossary:glossary” as per JSON-LD semantics. In other words, JSON-LD normalizes “gl:glossary” into an expanded form with the URI and without the “gl” prefix. This means that we do not need to lock down a specific prefix as any prefix defined in the @context will do. This looks a pretty simple approach if we want to go that route. JSON-LD seems to follow document-oriented concepts found in XML, which is good because it supports XLIFF-JLIFF compatibility with respect to modules and extensions. Thinking XML prefixes simply translate to JSON-LD @context entries and back. Having read through this more carefully, I'd agree.  The only minor note I'd make is that based on the language in the spec and the examples it contains, since the XLIFF 2.0 namespaces use colons themselves: urn:oasis:names:tc:xliff: glossary:2.0:glossary We would need to define the prefix as  "gls": "urn:oasis:names:tc: xliff:glossary:2.0:"     <-- note trailing colon so that "gls:glossary" would expand to "urn:oasis:names:tc:xliff: glossary:2.0:glossary".  That is, my reading of the JSON-LD spec is that the colon in the compact notation is not considered part of the expanded name, so we need to include it in our declared namespace. But this mechanism looks good, and the existence of compact IRIs is enough to make me think we should use colon as a separator and not worry so much about the JS access mechanisms.  Lookup by string key will be ok.

Hi all,   Looking more into the namespace notation: We floated the idea that we could use predefined prefixes (like “gls_glossary”) for the modules and full URI (like “myNamespaceURI myprop”) for extensions.   But there is one funny twist about the distinction between modules and extensions in XLIFF: Not all tools supports all modules, and for such tools an unsupported module is pretty much like an extension. So how should a tool deal with unsupported modules?   For example, the Okapi XLIFF Toolkit does not support the Format Style module , should we output:         "notes": [         {           "priority": 9,           "text": "Note for f1",           "http://myNamespaceURI attr": "value-in-note",           "urn:oasis:names:tc:xliff:fs:2.0 fs": "b"         }       ],   Or         "notes": [         {           "priority": 9,           "text": "Note for f1",           "http://myNamespaceURI attr": "value-in-note",           "fs_fs": "b"         }       ],   The second option would mean each tool would have to somehow know all namespaces for all modules and manage to somehow create an output different from the extensions output. This goes against the “you don’t have to implement all modules” assumption that XLIFF 2 has.   Thoughts?   Cheers, -yves     From: Robert van Engelen [mailto:engelen@genivia.com] Sent: Tuesday, May 23, 2017 11:11 AM To: Yves Savourel <ysavourel@enlaso.com> Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] Modules and extensions     I’m inclined to stick to _ to separate prefix from name, assuming _ are forbidden in prefixes and names by self-imposed JLIFF conventions. Underscore is at least widely supported in variable names.   Other programming languages may not accept $ in hard-coded property/variable names (i.e. console.log(x.name.b) is "hard-coded" and so is console.log(x[“name.b”])  also hard-coded, but with a period in the property name that requires quotes).   - Robert       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 May 23, 2017, at 1:03 PM, Yves Savourel < ysavourel@enlaso.com > wrote:   Regarding separator, from quick tests:   Dollar-sign would work, but not period, IMO:   var x = {"name$b": "text"}; console.log(x.name$b);   à   ok   var x = {"name.b": "text"}; console.log(x.name.b);   à   error   More tests are probably needed.   cheers, -yves