OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC

Hi all,   Trying my luck with the Metadata module I’ve noticed a few things:     --- There is an option id field for metadata, so we cannot do this:   "metadata" : [ { "category" : "document_xml_attribute", …   We have to have something like:   "metadata" : { "groups" : [ { "category" : "document_xml_attribute", …     --- There is nothing in the XLIFF specification that says a meta@type has a unique value within a metaGroup. So, I’m not sure we can do this:   "meta": [ { "version" : "3" }, { "phase": "draft" }, …   as "version" and "phase" may exist several times in the same group. I know, there is little chance it would be the case in practice. Do we want to chance this?     --- Should not "meta" be "metas"? It does look weird, but maybe consistency is worth that?     --- There is the question of the namespaces that is still to resolve obviously. But that is a separate issue.     --- The latest update of Lynx with JLIFF is here: http://okapiframework.org/snapshots/okapi-xliffLib_JLIFF_1.1.6-SNAPSHOT.zip     cheers, -yves   Yves Savourel Localization Solutions Architect ENLASO ® 4888 Pearl East Circle Suite 300E Boulder Colorado 80301 t: 303.945.3759 f: 303.516.1701 An ISO 9001:2015 certified company   Confidentiality Notice The information in this transmittal may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  

On Mon, May 8, 2017 at 3:18 PM, Yves Savourel < ysavourel@enlaso.com > wrote: --- There is an option id field for metadata, so we cannot do this:   "metadata" : [ { "category" : "document_xml_attribute", …   We have to have something like:   "metadata" : { "groups" : [ { "category" : "document_xml_attribute", … Unfortunately, you are correct.  The XLIFF spec doesn't even explain why this @id exists!  Ugh.   --- There is nothing in the XLIFF specification that says a meta@type has a unique value within a metaGroup. So, I’m not sure we can do this:   "meta": [ { "version" : "3" }, { "phase": "draft" }, …   as "version" and "phase" may exist several times in the same group. I know, there is little chance it would be the case in practice. Do we want to chance this? I think the answer here needs to be coordinated both with the OM and probably with the regular TC as well.  As written, you're right that JLIFF is taking a risk.  I think this also gets at the point you were making in your other email about working entirely from XLIFF as opposed to working through an OM. --- Should not "meta" be "metas"? It does look weird, but maybe consistency is worth that? I don't have a strong opinion. However, I do have a question about whether the way nested metagroups are working caused you any problems.  For example (from jliff-example3-0.9.3.json) --        "metadata" : [         {           "category": "document",           "appliesTo": "source",           "meta": [             { "version" : "3" },             { "phase": "draft" },             {               "category": "subgroup",               "meta": [                 { "breakfast" : "eggs" }               ]             }           ]         }       ] From an implementation standpoint, do those objects need some sort of hint to deserializers that the first two (version, phase) are meta objects, and the third one is a metaGroup?

Ø   However, I do have a question about whether the way nested metagroups are working caused you any problems.  For example (from jliff-example3-0.9.3.json) –  Ø   … Ø   From an implementation standpoint, do those objects need some sort of hint to deserializers that the first two (version, phase) are meta objects, and the third one is a metaGroup?   It may be an issue. I have not worked much on the deserialization part, but initially I had the meatGroup and the meta objects share a “isGroup” field, so they could be stored in a single array of objects. After I’ve looked at the Github examples, I figured we could use the “meta” (or “metas”) key to distinguish group from meta entry. I suppose it also depends on how the deserialization is done: using annotations and automated (un/)marshalling may require extra things while doing it manually may be more flexible.     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: Chase Tingley [mailto:chase@spartansoftwareinc.com] Sent: Monday, May 8, 2017 4:57 PM To: Yves Savourel <ysavourel@enlaso.com> Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] JLIFF and Metadata       On Mon, May 8, 2017 at 3:18 PM, Yves Savourel < ysavourel@enlaso.com > wrote: --- There is an option id field for metadata, so we cannot do this:   "metadata" : [ { "category" : "document_xml_attribute", …   We have to have something like:   "metadata" : { "groups" : [ { "category" : "document_xml_attribute", …   Unfortunately, you are correct.  The XLIFF spec doesn't even explain why this @id exists!  Ugh.     --- There is nothing in the XLIFF specification that says a meta@type has a unique value within a metaGroup. So, I’m not sure we can do this:   "meta": [ { "version" : "3" }, { "phase": "draft" }, …   as "version" and "phase" may exist several times in the same group. I know, there is little chance it would be the case in practice. Do we want to chance this?   I think the answer here needs to be coordinated both with the OM and probably with the regular TC as well.  As written, you're right that JLIFF is taking a risk.  I think this also gets at the point you were making in your other email about working entirely from XLIFF as opposed to working through an OM.   --- Should not "meta" be "metas"? It does look weird, but maybe consistency is worth that?   I don't have a strong opinion.   However, I do have a question about whether the way nested metagroups are working caused you any problems.  For example (from jliff-example3-0.9.3.json) --          "metadata" : [         {           "category": "document",           "appliesTo": "source",           "meta": [             { "version" : "3" },             { "phase": "draft" },             {               "category": "subgroup",               "meta": [                 { "breakfast" : "eggs" }               ]             }           ]         }       ]   From an implementation standpoint, do those objects need some sort of hint to deserializers that the first two (version, phase) are meta objects, and the third one is a metaGroup?    

Based on this thread and discussions on the last call, I've pushed some schema changes to: Add the 'id' attribute inside the metadata object Support redundant keys by changing meta objects to support explicit "type" and "value" properties. This latter change makes the module a fair bit clunkier, but without clarification from the OM or XLIFF we are risking data loss between serializations if we don't do it. I have also rearranged the examples slightly: the jliff-example#.json files are now the current examples.  Keeping the per-version examples as separate files was causing problems.  The older versions are available in the repository history. On Tue, May 9, 2017 at 5:45 AM, Yves Savourel < ysavourel@enlaso.com > wrote: Ø   However, I do have a question about whether the way nested metagroups are working caused you any problems.  For example (from jliff-example3-0.9.3.json) –  Ø   … Ø   From an implementation standpoint, do those objects need some sort of hint to deserializers that the first two (version, phase) are meta objects, and the third one is a metaGroup?   It may be an issue. I have not worked much on the deserialization part, but initially I had the meatGroup and the meta objects share a “isGroup” field, so they could be stored in a single array of objects. After I’ve looked at the Github examples, I figured we could use the “meta” (or “metas”) key to distinguish group from meta entry. I suppose it also depends on how the deserialization is done: using annotations and automated (un/)marshalling may require extra things while doing it manually may be more flexible.     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: Chase Tingley [mailto: chase@ spartansoftwareinc.com ] Sent: Monday, May 8, 2017 4:57 PM To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open. org > Subject: Re: [xliff-omos] JLIFF and Metadata       On Mon, May 8, 2017 at 3:18 PM, Yves Savourel < ysavourel@enlaso.com > wrote: --- There is an option id field for metadata, so we cannot do this:   "metadata" : [ { "category" : "document_xml_attribute", …   We have to have something like:   "metadata" : { "groups" : [ { "category" : "document_xml_attribute", …   Unfortunately, you are correct.  The XLIFF spec doesn't even explain why this @id exists!  Ugh.     --- There is nothing in the XLIFF specification that says a meta@type has a unique value within a metaGroup. So, I’m not sure we can do this:   "meta": [ { "version" : "3" }, { "phase": "draft" }, …   as "version" and "phase" may exist several times in the same group. I know, there is little chance it would be the case in practice. Do we want to chance this?   I think the answer here needs to be coordinated both with the OM and probably with the regular TC as well.  As written, you're right that JLIFF is taking a risk.  I think this also gets at the point you were making in your other email about working entirely from XLIFF as opposed to working through an OM.   --- Should not "meta" be "metas"? It does look weird, but maybe consistency is worth that?   I don't have a strong opinion.   However, I do have a question about whether the way nested metagroups are working caused you any problems.  For example (from jliff-example3-0.9.3.json) --          "metadata" : [         {           "category": "document",           "appliesTo": "source",           "meta": [             { "version" : "3" },             { "phase": "draft" },             {               "category": "subgroup",               "meta": [                 { "breakfast" : "eggs" }               ]             }           ]         }       ]   From an implementation standpoint, do those objects need some sort of hint to deserializers that the first two (version, phase) are meta objects, and the third one is a metaGroup?    

Hi all,   I’ve updated the jliff branch of the XLIFF-Toolkit to write the metadata based on Chase’s changes. There is also now a reader that can read it back. One difference: for now it uses a “mda_” prefix. All this is obviously under construction and will be adjusted as the TC decides things.   Compiled toolkit: http://okapiframework.org/snapshots/okapi-xliffLib_JLIFF_1.1.6-SNAPSHOT.zip   Code: https://bitbucket.org/okapiframework/xliff-toolkit/branch/jliff   Cheers, -yves   PS: I think I should be able to make it to the call tomorrow. But I’m not 100% sure.     From: Chase Tingley [mailto:chase@spartansoftwareinc.com] Sent: Sunday, May 21, 2017 3:33 PM To: Yves Savourel <ysavourel@enlaso.com> Cc: XLIFF OMOS TC <xliff-omos@lists.oasis-open.org> Subject: Re: [xliff-omos] JLIFF and Metadata   Based on this thread and discussions on the last call, I've pushed some schema changes to: Add the 'id' attribute inside the metadata object Support redundant keys by changing meta objects to support explicit "type" and "value" properties. This latter change makes the module a fair bit clunkier, but without clarification from the OM or XLIFF we are risking data loss between serializations if we don't do it.   I have also rearranged the examples slightly: the jliff-example#.json files are now the current examples.  Keeping the per-version examples as separate files was causing problems.  The older versions are available in the repository history.     On Tue, May 9, 2017 at 5:45 AM, Yves Savourel < ysavourel@enlaso.com > wrote: Ø   However, I do have a question about whether the way nested metagroups are working caused you any problems.  For example (from jliff-example3-0.9.3.json) –  Ø   … Ø   From an implementation standpoint, do those objects need some sort of hint to deserializers that the first two (version, phase) are meta objects, and the third one is a metaGroup?   It may be an issue. I have not worked much on the deserialization part, but initially I had the meatGroup and the meta objects share a “isGroup” field, so they could be stored in a single array of objects. After I’ve looked at the Github examples, I figured we could use the “meta” (or “metas”) key to distinguish group from meta entry. I suppose it also depends on how the deserialization is done: using annotations and automated (un/)marshalling may require extra things while doing it manually may be more flexible.     Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ®   From: Chase Tingley [mailto: chase@spartansoftwareinc.com ] Sent: Monday, May 8, 2017 4:57 PM To: Yves Savourel < ysavourel@enlaso.com > Cc: XLIFF OMOS TC < xliff-omos@lists.oasis-open.org > Subject: Re: [xliff-omos] JLIFF and Metadata       On Mon, May 8, 2017 at 3:18 PM, Yves Savourel < ysavourel@enlaso.com > wrote: --- There is an option id field for metadata, so we cannot do this:   "metadata" : [ { "category" : "document_xml_attribute", …   We have to have something like:   "metadata" : { "groups" : [ { "category" : "document_xml_attribute", …   Unfortunately, you are correct.  The XLIFF spec doesn't even explain why this @id exists!  Ugh.     --- There is nothing in the XLIFF specification that says a meta@type has a unique value within a metaGroup. So, I’m not sure we can do this:   "meta": [ { "version" : "3" }, { "phase": "draft" }, …   as "version" and "phase" may exist several times in the same group. I know, there is little chance it would be the case in practice. Do we want to chance this?   I think the answer here needs to be coordinated both with the OM and probably with the regular TC as well.  As written, you're right that JLIFF is taking a risk.  I think this also gets at the point you were making in your other email about working entirely from XLIFF as opposed to working through an OM.   --- Should not "meta" be "metas"? It does look weird, but maybe consistency is worth that?   I don't have a strong opinion.   However, I do have a question about whether the way nested metagroups are working caused you any problems.  For example (from jliff-example3-0.9.3.json) --          "metadata" : [         {           "category": "document",           "appliesTo": "source",           "meta": [             { "version" : "3" },             { "phase": "draft" },             {               "category": "subgroup",               "meta": [                 { "breakfast" : "eggs" }               ]             }           ]         }       ]   From an implementation standpoint, do those objects need some sort of hint to deserializers that the first two (version, phase) are meta objects, and the third one is a metaGroup?      

The Web version of Okapi Lynx has been also updated. You can now generate JLIFF output from a given XLIFF input.   http://okapi-lynx.appspot.com/jliff   All this is very preliminary obviously: Not all elements/attributes are written; no support for inline codes data; etc.   Cheers, -yves