RE: [xliff] What does/should "simplify" mean? (RE: [xliff] Minimum set o

Hi Bryan,

When thinking on an element for the standard, think on the value it ads as data holder. If it doesn’t add any meaningful value, it probably shouldn’t be there.

In terms of the old XLIFF 1.2:

- <external-file> is only useful to contain an attribute that points to the location of the file. The attribute can live at a higher level as well, so this element is not strictly required. It does not contain any data.

- <skl> is there to contain either one <external-file> or one <internal-file>. If <external-file> is not really required, we can move the data from <internal-file> a level up and store it inside <skl>.

Current draft uses <skeleton> but we can rename it as <skl> for backwards compatibility. There is no data loss at all.

Back to XLIFF 1.2, <header> contains <skl> and many other elements with information that applies to the whole <file>. In this case, having <header> is useful as container for diverse data. Nice to have.

In XLIFF 2.0 we don’t have yet diverse data to put in <header>. The only thing we have for the time being is <skeleton>. Unless we define additional elements with data that applies to the whole file, placing <skeleton> in <file> is good enough.

There are many things we have not designed yet for XLIFF 2.0, like holders for word counts or processing stage data (the old <phase>). These things are optional and not required at XLIFF creation time. If we add the corresponding modules, we can introduce <header> as natural container that would be nice to have.

Do we need <header>? The answer is probably not yet, but maybe later.

What does <body> contain in the old version? Just a collection of <file> elements. We also have other containers for collections in XLIFF 2.0, like <notes> or <matches>, so a collection container for <file> elements would be good for consistency. Perhaps <files> would be a better name.

So, we have these main use cases for elements:

1) contains PCDATA (<source>, <target>, <simpleNote>)

2) contains a collection of similar elements and no data (<matches>, <notes>)

3) contains a set of different but related elements and no data (<file>, <unit>, <match>, <segment>, <ignorable>)

4) acts as placeholder to indicate where extracted data should be placed on reverse conversion (empty inline elements)

A new element that doesn’t have one of those roles is probably not needed.

A new element that has the same functionality of an existing one is probably not needed. Instead of adding a new element it may be better to generalize the existing one.

Back to your minimum set of elements:

- <external-file> does not fulfill any of the above use cases.

- <skl> would only contain one element, so it does not have any of the roles mentioned above.

- For the time being, <header> would only contain one element and thus would not really be necessary

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: Wednesday, March 21, 2012 6:37 PM
To: Rodolfo M. Raya; xliff@lists.oasis-open.org
Subject: [xliff] What does/should "simplify" mean? (RE: [xliff] Minimum set of container elements for XLIFF 2.0)

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)?

<doc>

<file>

<head>

<title>Animals</title>

<keyword>Whale</keyword>

</keywords>

</workflow>

</head>

<body>

</graphic>

</div>

<para>Cats are smaller than dogs.</para>

<list>

<nitem>Litter</nitem>

<nitem>Meals</nitem>

<list>

</list>

<list>

<bitem>Vet bills</bitem>

<bitem>Flea collars</bitem>

</list>

</div>

</body>

</file>

<doc>

<title type="meta">Animals</title>

<keyword>Whale</keyword>

<para>Cats are smaller than dogs.</para>

<nitem>Litter</nitem>

<nitem>Meals</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 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

xliff message