RE: [xliff-omos] Modules and extensions

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.

xliff-omos message