RE: [xliff-omos] Modules and extensions

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

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.

xliff-omos message