[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff-omos] Modules and extensions
Hi all,
Agreed.
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.
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 engelen@genivia.com
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]