[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Minimum set of container elements for XLIFF 2.0
I will take a look at the draft specification for sure. While your points are logical, I suppose the " (B34) Minimum set of container elements" wiki entry can be seen as a counter-proposal to some of what you've drafted so far.
Likewise, Yves' wiki entry, "(Y27) Grouping of Entries" (http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Grouping ) can be seen as a counter-proposal to your point about not needing <group>.
We'll just have to see how it plays out.
Personally, I see value in <header> / <body>, and in <internal-file> / <external-file> (though I kind of like your idea about an external file just being an attribute). I do see a need to accommodate both internal and external within the same <file>.
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.