Hi Rodolfo,
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>.
Thanks,
Bryan
From: [mailto:] On Behalf Of Rodolfo M. Raya
Sent: Monday, March 19, 2012 2:23 PM
To:
Subject: RE: [xliff] Minimum set of container elements for XLIFF 2.0
Hi Bryan,
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.
Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
From: [mailto:] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 19, 2012 4:42 PM
To:
Subject: [xliff] Minimum set of container elements for XLIFF 2.0
Hello,
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)
<xliff>1
|
|
+--- <file>+
|
+--- <header>?
| |
| +--- <skl>?
| |
| +--- <internal-file>?
| |
| +--- <external-file>?
|
|
+--- <body>1
|
+--- <group>*
|
+--- <unit>*
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).
Thanks,
Bryan Schnabel
Content Management Architect
Phone: 503.627.5282
www.tektronix.com
