Re: [xliff-omos] Modules and extensions

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 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.

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.

xliff-omos message