Re: [xliff-omos] Recognizing Modules

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.

xliff-omos message