Interesting suggestion to use âits_moduleâ as a wrapper.
IMO with respect to the naming of JLIFF properties (and the JLIFF structure overall) it is beneficial to:
- Make documents and schemas reasonably legible to humans.
- Prevent ambiguity at all cost.
- Limit the complexity of document processing and schema validation.
- Make the JLIFF document format compatible as much as possible with XLIFF and the OM in general, so property names should reflect XLIFF/OM.
The âprefix_â format is just meant to enhance legibility of the JLIFF documents and JLIFF schema for modules, with little or no impact on processing cost and does not introduce structural ambiguity.
The current JLIFF schema uses the âprefix_â format to distinguish module properties from other object properties, i.e. to enhance legibility. A module typeâs local properties however are not prefixed, but we could decide to do so though the result would appear more complex than necessary. Either way, the result is still unambiguous since property names cannot conflict, even with extensions because these will use fully qualified names that are resolved with a JSON-LD context.
Given the suggestion to use âmoduleâ wrappers, I worry that processing complexity would perhaps be increased by the indirection caused by wrapping module properties with a âmoduleâ property or âits_moduleâ property, though I suppose the added complexity depends on the implementation.
I have one more question for the committee on a related matter:
There are actually two ITS module prefixes currently in use: âitsâ and âitsmâ where the latter is solely used with the âitsm_domainsâ property. Since these two prefixes are associated with the same module and JLIFF does not use namespace URIs that must be resolved, canât we just use one ITS prefix âitsâ and replace âitsmâ with âitsâ to rename âits_domains"?
Thanks!
Dr. Robert van Engelen - www.linkedin.com/in/robertvanengelen/
Genivia Inc
On Sep 18, 2018, at 7:15 AM, Phil Ritchie <phil.ritchie@vistatec.com> wrote:
All
I spent some time on this. The addition of the module prefix happens at the parent property level so a simple renaming of those parent properties can accommodate the non-prefixed sub-properties scenario.
I am wondering though, especially for its, whether it is better to have a single "its_module" property which takes an its object with the rest of the properties. For example, at the moment file, unit, group, and the inlines have ~30 its related properties.
{
"srcLang": "en",
"trgLang": "fr",
"jliff": "2.1",
"files": [
{
"id": "f1",
"subfiles": [
{
"canResegment": "no",
"id": "tu1",
"kind": "unit",
"subunits": [
{
"canResegment": "no",
"kind": "segment",
"source": [{
"text": "Sample segment."
}
],
"target": [{
"text": "Exemple de segment."
}
]
},
{
"kind": "ignorable",
"source": [{
"text": ""
}
],
"target": []
}
],
"its_revOrg": "...",
"its_revPerson": "...",
"its_revTool": "...",
"its_taIdent": "...",
"its_locQualityRatingScore": "..."
},
Versus
...
"subunits": [
{
"canResegment": "no",
"kind": "segment",
"source": [{
"text": "Sample segment."
}
],
"target": [{
"text": "Exemple de segment."
}
]
},
{
"kind": "ignorable",
"source": [{
"text": ""
}
],
"target": []
}
],
"its_module": {
"revOrg": "...",
"revPerson": "...",
"revTool": "...",
"taIdent": "...",
"locQualityRatingScore": "..."
}
},
If we then extrapolate that out for all modules we could abstract modules to a single "modules" property which takes a list of module objects
...
"subunits": [
{
"canResegment": "no",
"kind": "segment",
"source": [{
"text": "Sample segment."
}
],
"target": [{
"text": "Exemple de segment."
}
]
},
{
"kind": "ignorable",
"source": [{
"text": ""
}
],
"target": []
}
],
"modules": {
"its": {
"revPerson": "...",
"revTool": "...",
"taIdent": "...",
"locQualityRatingScore": "..."
},
"mda": {
}"...",
}
},
It might reduce schema changes when we add more modules in future.
Phil-----Original Message-----
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 Think Global
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.
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