RE: [xliff-omos] JLIFF and Metadata

[Yves Savourel <ysavourel@enlaso.com>]

Ø  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?