The specification draft already contains a tree.
If you look at the specification’s tree, you will see that we don’t need <header> or <body>. The element <skeleton> is directly included as optional child of <file>. We don’t need <internal-file> or <external-file>; if there is an internal skeleton, its data goes inside <skeleton>; if there isn’t any data, the location of the external skeleton can be added as attribute in <file>.
BTW, the core XML schema allows XML from any namespace inside <skeleton> as requested in the wiki.
We don’t need <group>. With <unit> as container of multiple <segment> elements we have enough. You can consider that the old <group> is equivalent to the new <unit> and the old <trans-unit> is the equivalent of the new <segment>/<ignorable> pair.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 19, 2012 4:42 PM
Subject: [xliff] Minimum set of container elements for XLIFF 2.0
I propose that while we are adding/changing features and functions, there is a minimum set of container elements (hierarchy) that we should preserve as framework for XLIFF 2.0. I think that set is: xliff, file, header, skl, internal-file, external-file, body, group, and unit.
(legend: 1 = one
+ = one or more
? = zero or one
* = zero, one or more)
| +--- <skl>?
| +--- <internal-file>?
| +--- <external-file>?
Of these I can only think that <group> could be controversial. I say that because it is feasible that it could change like <trans-unit> changed into <unit>. But I doubt the concept of grouping will go away.
And while it may be premature to say this, I envision that this will be a core feature (though ranking it as core is not part of this proposal).
Content Management Architect