Hello, I'm hearing a common theme. Simplification. We all want it. But what is it? Earlier in this thread my minimum set of container elements was refuted. The opinion was that (for example) <header> and <body> were not needed, and in another example that we could do with attributes what we used to do via wrapper elements. (for now I'll leave <group> out of the conversation since it is covered in another thread - but the principle for <group> could also apply here). So that made me wonder if we have a common, agreed upon definition of simplification. I think we do not. In fact, we might even have contradictory definitions. If something has fewer elements, is it automatically simpler? Which is more simple, example a) or example b)? a) <doc> <file> <head> <title>Animals</title> <keywords> <keyword>Dog</keyword> <keyword>Cat</keyword> <keyword>Whale</keyword> </keywords> <workflow> <author>Mary</author> <releaseDate>06May2011</releaseDate> <expireDate>20July2012</expireDate> </workflow> </head> <body> <div section="1"> <title>Dogs</title> <para>Dogs are good.</para> <graphic> <image src= > <title>Fido is nice</caption> </graphic> </div> <div section="2"> <title>Cats</title> <para>Cats are smaller than dogs.</para> <list> <nitem>Litter</nitem> <nitem>Meals</nitem> <list> <nitem>Cat food</nitem> <nitem>Milk</nitem> </list> </list> <list> <bitem>Vet bills</bitem> <bitem>Flea collars</bitem> </list> </div> </body> </file> <doc> b) <doc> <title type="meta">Animals</title> <keyword>Dog</keyword> <keyword>Cat</keyword> <keyword>Whale</keyword> <author>Mary</author> <releaseDate>06May2011</releaseDate> <expireDate>20July2012</expireDate> <title type="section" section="1">Dogs</title> <para>Dogs are good.</para> <image src= > <title type="image">Fido is nice</caption> <title type="section" section="2">Cats</title> <para>Cats are smaller than dogs.</para> <nitem>Litter</nitem> <nitem>Meals</nitem> <nitem indent="1">Cat food</nitem> <nitem indent="1">Milk</nitem> <bitem>Vet bills</bitem> <bitem>Flea collars</bitem> <doc> Contrary to what might be intuitive to others, I would pick a) as simpler. I draw upon my work to form this opinion. I support a Web Content Management System that exports/imports XLIFF files. It is super convenient/reliable for the web CMS to parse the <header> element for key metadata (having to do with workflow, for example), and to <skl> for document format information, and <body> for strings. Sure, it could be adapted to parse the whole <file> element and sort out what it needs, but that adds processing complexity. I also support an application that manages the translatable strings for our instrument software. Though it has a completely different API, it also *likes* the fact that it can find known datatypes within known wrappers. Same story with the Component Content Management System I support. Its XLIFF processing benefits from the <header>, <skl>, and <body> wrapper elements. But I can abstract beyond that. It also processes DITA maps and topics. One could argue that a concept topic would be simpler if we did away with the <prolog> and <conbody> wrapper elements (somewhat analogous to the <header> and <body> elements). But having wrapper tags make the processing much easier. Bottom line, I think we could/should come up with agreed upon criteria and apply it as a working principle to achieve simplification. But when I hear that <header> and <body>, and <group>, and others should be removed in the name of simplification, it makes me think we need some guidelines. If we do come up with this agreed upon guideline, I will reevaluate my proposal for minimum set of container elements. If my definition of "simpler" prevails, I will stand by it. If a different guideline emerges where simpler means eliminating elements like <header>, <body>, <group>, etc., I will withdraw it. 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 4:27 PM To:
xliff@lists.oasis-open.org Subject: RE: [xliff] Minimum set of container elements for XLIFF 2.0 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 ht tp://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