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
On Oct 7, 2017, at 3:05 PM, Chase Tingley <> 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 <> 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:
www.vistatec.com | ISO 9001 | ISO 13485 | ISO 17100
Think Global
From: [mailto:]
On Behalf Of Phil Ritchie
Sent: 27 June 2017 17:55
To: Robert van Engelen <>; Yves Savourel <>
Cc: XLIFF OMOS TC <>
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:
www.vistatec.com
|
ISO 9001
|
ISO 13485
|
ISO 17100
Think Global
From:
[mailto:]
On Behalf Of Robert van Engelen
Sent: 20 June 2017 19:18
To: Yves Savourel <>
Cc: XLIFF OMOS TC <>
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
On May 25, 2017, at 8:27 AM, Yves Savourel <> 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:]
Sent: Thursday, May 25, 2017 12:55 AM
To: Yves Savourel <>
Cc: XLIFF OMOS TC <>
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 <>:
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:]
Sent: Tuesday, May 23, 2017 11:11 AM
To: Yves Savourel <>
Cc: XLIFF OMOS TC <>
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
On May 23, 2017, at 1:03 PM, Yves Savourel <> 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
