As discussed in the meeting today. We opted for keeping the version and having the version tied to a specific context file in the spec. We would also tell people in the spec to make a local copy of the context files and not to hammer the official location from their implementations. We also decided to have two context files at the moment, one for the version 2.0 [with ctr and w/o its & itsm] and one for the version 2.1 [w/o ctr and with its & itsm] .. another for 2.2 etc in the future.. We need to look into a way of giving the context explicitly *and inline* for extensions that don't have OASIS guaranteed permalinks. BTW for its and itsm in 2.0 documents as well as for ctr in 2.1 documents. These examples can well serve for prototyping of extension support.. Cheers and thanks dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Tue, Dec 12, 2017 at 5:00 PM, Robert van Engelen <
engelen@genivia.com > wrote: My 2c: If the context link is always the same then we do not need it in a JLIFF doc since it is implied. If we don’t need it then we still need a jliff version identifying attribute. If instead the context link changes then there may be a penalty to load it from an external source every time a JLIFF document is accessed. This may double the networks access unless the content is cached. If the context at the link source changes then loading is still required, unless we include a time stamp for effective caching. - Robert Dr. Robert van Engelen, CEO/CTO Genivia Inc. voice: (850) 270 6179 ext 104 fax: (850) 270 6179 mobile: (850) 264 2676 LinkedIn:
www.linkedin.com/in/ robertvanengelen/
engelen@genivia.com On Dec 11, 2017, at 8:22 PM, Chase Tingley <
chase@spartansoftwareinc.com > wrote: Yes, my thought was that it would be easier to reference the context. The fictional URI I used in the examples in my FEISGILTT slides was: { "@context":"
http://docs.oasis- open.org/xliff-omos/jliff/v2. 1/jliff-v2.1.jsonld ", "jliff": "2.1" "srcLang": "en" ... } It seemed to me that if we used @context in this way, then the "jliff" attribute would itself become redundant, since we could use the context reference as a unique version identifier. On Thu, Dec 7, 2017 at 1:08 PM, Robert van Engelen <
engelen@genivia.com > wrote: Looking at the JSON-LD spec, it appears that contexts can be either in-line or referenced. We can support both to comply with JSON-LD. Compact IRIs (JSON-LD 1.0 section 6.3) and “The Context” (JSON-LD 1.0 section 5.1) are applicable. See Examples 4 (referencing a JSON-LD context) and 5 (in-line context definition) in 5.1. I still need to update the schema to permit context referencing and I’m figuring that out how right now. - Robert Dr. Robert van Engelen, CEO/CTO Genivia Inc. voice: (850) 270 6179 ext 104 fax: (850) 270 6179 mobile: (850) 264 2676 LinkedIn:
www.linkedin.com/in/robertvane ngelen/
engelen@genivia.com On Dec 7, 2017, at 3:18 PM, David Filip <
david.filip@adaptcentre.ie > wrote: Robert, Chase, I think that we discussed that the context shouldn't be embedded in JLIFF instances. Just referenced? Cheers dF On Dec 7, 2017 18:28, "Robert van Engelen" <
engelen@genivia.com > wrote: Chase, IMO this looks good. I’ll work on the schema to incorporate contexts, such that the placement of the context in a JLIFF document is near the root. I think it actually should be part of the root like so: { "jliff": "2.1", "srcLang": "en", "trgLang": "fr”, “@context”: { "xliff": "urn:oasis:names:tc:xliff:docu ment:2.0”, "gls": "urn:oasis:names:tc:xliff:glos sary:2.0”, …etc etc... }, "files": [ Which should make the context visible to all modules/extensions defined as ‘metadata’ in JLIFF. - Robert Dr. Robert van Engelen, CEO/CTO Genivia Inc. voice: (850) 270 6179 ext 104 fax: (850) 270 6179 mobile: (850) 264 2676 LinkedIn:
www.linkedin.com/in/robertvane ngelen/
engelen@genivia.com On Dec 2, 2017, at 6:15 PM, Chase Tingley <
chase@spartansoftwareinc.com > wrote: Hi all, I've pushed a working draft of a JSON-LD context file to github. Currently, this just defines all of the namespaces/prefixes from the XLIFF spec. A few notes about issues we should work through: I've included the 'xliff' prefix. In practice, we've been assuming that this namespace is implicit for the elements in JLIFF. Is there a reason to define it? I'm not sure. I worked from the XLIFF 2.1 document, but I also included the CTR namespace from 2.0. We haven't discussed whether we should support the 2.0 CTR (or even, more generally, whether JLIFF support starts explicitly at XLIFF 2.0 or 2.1.)