On Mon, May 8, 2017 at 3:18 PM, Yves Savourel <> 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?
