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