Hi Robert, Phil,
I agree with Phil that this is undesirable..
This type of repetition shouldn't be allowed.
This is very different from the OM and would not be interoperable with the XML pipeline. You'd need to expand multiple coresponding XLIFF files when going XML. And I don't think we want to go there.
Each JLIFF should have just a single instance of root content..
The values governing what type this instance is should not repeat the names from the lower level, because the reason to introduce the root content characteristics was that the lower level content was ambiguous from the OM point of view.
So this is correct, just that the values to govern the content selection should be and map like this
liff -> content must be "files"
file/fragment -> content should be an unlimited choice group of "groups" and "units"
OR we could introduce "subfiles" (by analogy tu "subunits" which can intermix segments and ignorables) that could intermix group and unit content objects.
group -> content should be an unlimited choice group of "groups" and "units"
OR we could introduce "subgroups" that could intermix group and unit content objects.
Now that I wrote all of the above, it seem to me that we could and should get rid of the top level content property by simply introducing more content types. This makes the content unambiguous from the OM and XLIFF points of view.
We'd have "files" which equals liff in OM, "subfiles" which equals file, "subgroups" which equals group. And "subunits" for unit.
"subfiles" and "subgroups" have exactly the same data model in JLIFF, which is fine because they have the same models in OM. We just call them differently to preserve the OM level, which is critical for switching pipelines..