All Explicitly having properties for all of the ITS (module) values does mean that several class definitions have to have 30+ property getters/setters repeated which feels wrong to me. Anyway I have proceeded on that basis for the time being in order to see what the overall effect of serialization and conversion from XML is. 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 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: Robert van Engelen <
engelen@genivia.com> Sent: Tuesday 25 September 2018 19:05 To: Phil Ritchie <
phil.ritchie@vistatec.com> Cc: XLIFF OMOS TC <
xliff-omos@lists.oasisopen.org> Subject: Re: [xliff-omos] JLIFF versus XLIFF modules: prefixed JSON (sub)property names? Phil et al., 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 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.
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