[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-omos] Modules and extensions
Ø Perhaps the downside is that JSON rendition with fully-qualified names is more verbose than XML QNames. I suppose fully-qualified names will not be prevalent in JLIFF so JLIFF fragments do not blow up in size compared to XML, but could be wrong.
I’m afraid there are quite a few elements/attributes with namespaces in XLIFF.
Maybe the prefixes might not be so bad: the prefixes for the modules are pre-defined and reserved, so for a glossary gls_glossary (with _ or whatever separator decided upon) would not be confused with another element in another namespace. Essentially the mapping table would be to get the version of the module.
As for extensions, while they are not predictable, we also have to remember that they may be registered too, so they should have some sort of predictability too.
I share your concerns. Also, I believe JSON-LD has disadvantages with respect to serialization frameworks. And introducing our own prefix-URI binding mechanism to define XML-like QNames is not preferable to support existing frameworks.
RFC3986 https://tools.ietf.org/html/rfc3986 section 2 says:
"A URI is composed from a limited set of characters consisting of
digits, letters, and a few graphic symbols. A reserved subset of
those characters may be used to delimit syntax components within a
URI while the remaining characters, including both the unreserved set
and those reserved characters not acting as delimiters, define each
component's identifying data."
Perhaps an ad-hoc name qualification mechanism can be used. Since JSON property names are strings, URIs can be easily embedded without breaking JSON parsers.
For example, the space character U+0020 suffices to separate a URI from an unqualified name in a string that contains both:
JSON property names are strings, so this is perfectly valid. Also, using the space character may also be more visually appealing than a character that is graphically rendered such as ^ (hat). I also suspect that spaces are forbidden in JLIFF names, preventing any ambiguity about the placement of the space.
Perhaps the downside is that JSON rendition with fully-qualified names is more verbose than XML QNames. I suppose fully-qualified names will not be prevalent in JLIFF so JLIFF fragments do not blow up in size compared to XML, but could be wrong.
For hard-code JLIFF serializers, the property names will be a bit more cumbersome to use as a consequence e.g. obj[“URI name”] compared to obj.name (and obj.prefix$name if homegrown prefixes are introduced).
Dr. Robert van Engelen, CEO/CTO Genivia Inc.
voice: (850) 270 6179 ext 104