Re: [xliff-omos] Modules and extensions

[Chase Tingley <chase@spartansoftwareinc.com>]

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.