Hi Phil, all, we were tending to a consensus in couple of last calls to use an underscore "_" separator to indicate module objects. I think we decided only to underscore-prefix top level objects, which can however be leaves for many "its_" occurrences. We didn't want to use colon ":" because colon triggers JSON LD context processing and we decided long ago against explicitly including core or module contexts in JLIFF schema or instances. This knowledge should be only documented in the prose spec. In a sense, a parser wouldn't know if an object comes from a module. The underscore prefix is just for human readability. I guess parsers could implement a custom module logic relying on the "_" separator. But I am not sure how useful that would be because I assume that the JSON schema does give u a cardinality that indicates the object being optional (zero or one, zero, one, or more). @Robert, can you please confirm if and how the JSON schema expresses cardinality/optionality? I am just assuming that it has this capability analogically to XML Schema, and we would be in trouble if it didn't ;-0 The only drawback seems that generic parsers cannot tell if something is a module or optional core. But the situation is not much worse than in XML. In XML u know that something comes from a foreign namespace, but u need to implement custom code to know which namespaces are absolutely protected and u must roundtrip them or if the namespace is an extension and thus can eventually be dumped. In a sense, the situation seems better in JLIFF. Everything colon-prefixed is an extension, so u SHOULD rountrip it. Everythin w/o a prefix or informally underscore-prefixed MUST be roundtripped, even though you might not understand it in case of modules. Not understanding Core of course shouldn't be an option.. I hope this helps dF Dr. David Filip =========== Convenor, JTC 1/SC 42/WG 3 Trustworthiness of AI National mirror chair, NSAI TC 02/SC 18 AI Head of the Irish national delegation, ISO/IEC JTC 1/SC 42 AI Chair & Editor, OASIS XLIFF OMOS TC Secretary & Lead Editor, OASIS XLIFF TC NSAI expert to ISO/IEC JTC 1/SC 38 Cloud Computing, ISO TC 37/SC 3 Terminology management, SC 4 Language resources, SC 5 Language technology Moravia Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Fri, Nov 2, 2018 at 9:33 AM Phil Ritchie <
phil.ritchie@vistatec.com > wrote: All Dumb question: In the instance that we go with the jliff-schema-2.1-no-prefix so that for example, ITS properties appear as: element-sm : { properties : { id : locQualityIssueComment : locQualityIssueSeverity : } } How would a parsing application know (if indeed it ever needed to) that locQuality* come from a module? I guess this comes back to my thinking that modules would be wrapped so that their root property would have the prefix and their individual properties not: element-sm : { properties : { id : its:locQualityIssue : { locQualityComment : locQualityIssueSeverity : } } } 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.