Hi again,
We certainly need to start limiting the number of features in the wiki. Please add an item in the agenda for discussing how to do that.
Regards,
Rodolfo
--
Rodolfo M. Raya rmraya@maxprograms.com
Maxprograms http://www.maxprograms.com
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 19, 2012 8:17 PM
To: Rodolfo M. Raya; xliff@lists.oasis-open.org
Subject: RE: [xliff] Minimum set of container elements for XLIFF 2.0
Hi Rodolfo,
Once again your words make sense.
But I think the starting points you mentioned were exactly that, starting points.
And I think the goal to simplify (within reason and without doing harm) is very valid and should be taken into account as a working principle. And I can see how one could interpret the proposed minimum set of required elements proposal as counter to that principle.
The counterpoint is that one could also argue that the elements mentioned are reasonable and add value for readability and process-ability -- and to remove them would add ambiguity. As I said before, that's a judgment that the TC will need to make.
So this brings me to your statement that I completely sympathize with:
> I think it would be appropriate to mention a feature request
> and explain the reasoning behind it in a TC meeting before
> adding it to the wiki
We do not have such a policy in place. In fact, we encourage people to add proposed features to section 2 of the wiki, with no restrictions.
I can see your wish (and my wish) to stop adding features and get XLIFF 2.0 published. One way toward this is to invoke a policy like the one you suggest, and to attach strict criteria for qualifying to add a new feature. Another way is to revisit the idea of setting a calendar date goal. I can see pros and cons with each.
If you want to propose a change in policy, please feel free to bring it up on the list, or have me add it to the agenda, under current business. I think it's a worthy cause.
Thanks,
Bryan
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Monday, March 19, 2012 3:44 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Minimum set of container elements for XLIFF 2.0
Hi Bryan,
Last year I submitted a schema plus a descriptive PDF for review with the minimum required elements. The PDF and the schema were approved by the TC as starting point and the draft currently in SVN is based on that work.
One of the goals for XLIFF 2.0 is “simplify”. The current draft emphasizes that by not including elements that don’t provide useful content.
Yves’ request for grouping was added to the wiki and we never discussed it due to lack of time for technical work during our regular meetings. If it is approved for implementing, the corresponding element set will be added to the specification.
Your brand new proposal , (B34) “Minimum set of container elements”, was not discussed yet by the TC. Notice that it contradicts what we managed to minimally discuss and approve before as starting point.
I may be wrong, but I think it would be appropriate to mention a feature request and explain the reasoning behind it in a TC meeting before adding it to the wiki. We have items in the wiki that are not moving forward and we must start cleaning the list of features. It’s about time we stop adding feature requests and concentrate our efforts working on approved stuff. If we keep adding features, we will not be able to complete the specification in a reasonable time.
Regards,
Rodolfo
--
Rodolfo M. Raya rmraya@maxprograms.com
Maxprograms http://www.maxprograms.com
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 19, 2012 6:58 PM
To: Rodolfo M. Raya; xliff@lists.oasis-open.org
Subject: RE: [xliff] Minimum set of container elements for XLIFF 2.0
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: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Monday, March 19, 2012 2:23 PM
To: xliff@lists.oasis-open.org
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 rmraya@maxprograms.com
Maxprograms http://www.maxprograms.com
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 19, 2012 4:42 PM
To: xliff@lists.oasis-open.org
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
