OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-omos message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff-omos] JLIFF versus XLIFF modules: prefixed JSON (sub)property names?



Robert, All,

I've not had a chance to do any implementation work relating to modules so I can't express a preference based on ease of implementation.

My instinct tells me we should go for non-prefixed sub-properties.

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: phil.ritchie@vistatec.com
www.vistatec.com | ISO 9001 | ISO 13485 | ISO 17100 | ISO 27001
Vistatec
Think Global
FacebookLinkedInTwitterGoogle Plus
Vistatec Ltd. Registered in Ireland 268483. Registered Office, Vistatec House, 700, South Circular Road, Kilmainham. Dublin 8. Ireland.
The information contained in this message, including any accompanying documents, is confidential and is intended only for the addressee(s).
âThe unauthorized use, disclosure, copying, or alteration of this message is strictly forbidden.
If you have received this message in error please notify the sender immediately.

-----Original Message-----
From: xliff-omos@lists.oasis-open.org <xliff-omos@lists.oasis-open.org> On Behalf Of Robert van Engelen
Sent: Thursday 13 September 2018 16:27
To: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org>
Subject: [xliff-omos] JLIFF versus XLIFF modules: prefixed JSON (sub)property names?


Dear TC members,

The JLIFF TC is converging on a JLIFF schema draft with examples. It was suggested in our last teleconference to raise the following question pertaining the proposed use of prefixed JSON property names in JLIFF to represent JLIFF modules.

First, let me explain that the JLIFF TC members evaluated different ways to represent modules and extensions in JLIFF, while attempting to ensure a high level of compatibility to the XLIFF OM. The TC favors prefixing module property names to distinguish modules from other JLIFF property names.

For example, in JLIFF the âmetadata" module is represented as a âmda_metadataâ property as shown in the example below:

{
"jliff": "2.0",
"srcLang": "en",
"files: [
"id": "f1",
"subfiles": {
"id="g1",
"kind": "group",
"name": "document",
"mda_metadata": {
"metaGroups": [
"category": "document_xml_attribute",
"meta": [
{ "type": "version", "value": 3 },
{ "type": "phase", "value": "draft" }
]
]
}
...
}

Which is compatible â essentially semantically isomorphic â to the same structure in XLIFF (part of an example taken from 5.4.4.2 XLIFF 2.1):

<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0"
xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0"
xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0"
version="2.0" srcLang="en">
<file id="f1">
<group id="g1" name="document">
<mda:metadata>
<mda:metaGroup category="document_xml_attribute">
<mda:meta type="version">3</mda:meta>
<mda:meta type="phase">draft</mda:meta>
</mda:metaGroup>
</mda:metadata>
â
</xliff>

Note that the JLIFF âmda_metadataâ object has non-prefixed sub-properties.

By contrast, the module schemas have elementFormDefault âqualified" with attributes unqualified by default. However, recall that plain JSON does not support the notion of XML-like attributes.

If all sub-properties of modules are prefixed, the resulting JLIFF document of the former JLIFF example shown above would be:

{
"jliff": "2.0",
"srcLang": "en",
"files: [
"id": "f1",
"subfiles": {
"id="g1",
"kind": "group",
"name": "document",
"mda_metadata": {
âmda_metaGroups": [
âmda_category": "document_xml_attribute",
âmda_meta": [
{ âmda_type": "version", âmda_value": 3 },
{ âmda_type": "phase", âmda_value": "draft" }
]
]
}
...
}

The question is, is this latter choice preferable (sub-properties are prefixed) or is the former choice (sub-properties are not prefixed) preferable from a design and/or implementation point of view? Perhaps there could be an unforeseen impact?

Note that the latter choice has all sub-properties prefixed even when the equivalent to the property in JLIFF is an unqualified XML attribute in XLIFF.

One important point of clarification: the TC decided to use an underscore â_â to separate the prefix from the module name. This is to prevent clashing with the JSON-LD resolution mechanism that replaces colon-qualified names with fully-qualified names. The TC proposes the use of JSON-LD to represent JLIFF extensions. This offers a decent scope of flexibility to developers and is closely aligned with the way XLIFF extensions are processed. An extension property name is resolved by prefix expansion as described in JSON-LD 4.4 âCompact IRIsâ https://json-ld.org/spec/latest/json-ld/#compact-iris where a compact IRI has the form âprefix:suffixâ with the âprefixâ bound to a URI in the given â@contextâ of the JLIFF document.

The most recent draft JLIFF 2.1 schema is accessible here:

https://github.com/oasis-tcs/xliff-omos-jliff/tree/master/JLIFF-schema-draft/JLIFF-2.1

Comments and feedback are welcome!

Thanks.


Dr. Robert van Engelen - www.linkedin.com/in/robertvanengelen/



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]