RE: [xliff] Metadata extensibility ballot

[Yves Savourel <ysavourel@enlaso.com>]

Hi Kevin, all,

It's nice to see some rationales applied to the decision process. I may not agree with all of your points, but at least I can understand and evaluate them. So thanks for this.

I've tried to summarize my arguments for each of your point below, but before to get to that, here is some overall thoughts on why, I think, we are having this debate. Maybe this will make you and others see the problem under a different light:


I think the core of the discussion is the difference between two broader views of XLIFF.

The first one (with meta-holder) is focused on going to the lower common denominators, so XLIFF tools are very simple to implement and developers have no way to get it wrong. Basically trying to re-do 1.2 but get it right.

The second one (with custom namespaces) is trying to make XLIFF fit into a larger world of data and metadata exchange, to allow it to be open to the future. Basically, trying to do 2.0 for a World 2.0.

I'm pretty sure that no matter how fast we can get 2.0 done, it will take quite some time for tools to implement it. So one of my fears is that by the time 2.0 becomes truly used, it will be outdated if we don't make it future-proof. In other words we need to think ahead, not backward.

The meta-holder option gets you a short-term fix. Custom namespaces gets you the longer-term solution.


Now into the points:

> Since there was no support for “namespaces only”, 
> it’s clear that there is strong support for elements 
> to a greater or lesser degree.

Or maybe it was to make sure "element only" didn't pass :)

My personal rational was that the "custom namespace only" option didn't really exist because with that option nothing prevents the users to define something like meta-holder, so we may as well provide an official one.


> Simplify the XLIFF 2.0 solution by having a single,
> clear option instead of 2 competing options.
> It’s clear from XLIFF 1.2 that choice leads to 
> fragmented support

I think what led to bad support in 1.2 was the fact that the specifications up to 1.2 were "too loose", not clear enough, had no defined processing expectations, too many 'undefined' default vales, etc.

Using one method or another for implementing extensions is not going to solve any of those issues.

What will reduce bad use of extensions is going to be: tighter definitions, single way of doing things (so I agree with you here), clear processing expectation, clear conformance statements defining when it's ok to have extensions, etc.

Then what is left are extensions that are relevant and should be implemented as extensions: things not defined by XLIFF. And for those, using custom namespaces would be much better.

In other words, the method we choose for implementing extensions should be the best for relevant extensions, not trying to solve the bad use of extensions 1.2 has. That is a different problem, with its own solutions. We have been, incorrectly, mixing both issues since day one.


> Tools providers only have to support one extensibility
> method, not two (we won’t force them to choose which)

Supporting different namespaces as a mechanism is something tools have to do anyway since 2.0 uses different namespaces for different modules. If we introduce meta-holder we are just making one of those namespaces a "bag-of-anything" more complicated to use for relevant extensions. (e.g. it needs its own non-standard validation).


> Ability for standardization/interoperability of 
> extensible metadata via commonly typed metadata types

But it'll be using a non-standard and limited way to specify types.
It would be far more standard and interoperable to allow the natural XML way to extend a vocabulary.

Only XLIFF tool implementing meta-holder will be able to validate the custom metadata in meta-holder, and only in the limited way meta-holder will allow. We won't be able to use a normal XML validation tool on meta-holder. To me that is going the opposite direction to standardization/interoperability.


> Greater predictability and integrity of XLIFF content;
> the open nature of namespaces risks introducing 
> invalid data to files

The open nature of namespace exists already in 2.0: Tools will have to face namespaces they don't necessarily support.

But you are right about meta-holder allowing more predictability. As Fredrik pointed out several weeks ago: it's a simple structure that is easily storable in database and various object models, while the tree-like structures of custom namespaces are more difficult to deal with.

The thing we manage with that is to make custom data easier to be preserve by the tools that do not support them.

At the same time, un-supported namespaces will still exist when a tool does not support some module. I certainly hope we can find a way to make those data also transparently carried during the process. If we do that, then the only advantage meta-holder becomes moot.

If not, ironically, we may end up with many tools preserving more efficiently non-standard metadata than standard ones (modules). I wouldn't want to have to explain how we got into that situation to interoperability fans.


> XLIFF 2.0 will require migration and conversion of data 
> anyway; moving away from namespaces is one such activity.

2.0 is not moving away from namespaces: it moves closer to them.
With meta-holder we will simply manage to reduce any relevant extensions to a simplistic and limited namespace.
Having custom namespace would greatly simplify the migration for all the parts 2.0 will not support. It will be far more complicated to do this with meta-holder.


You mentioned a couple of pros for custom namespaces. I'll add a few:

- Custom namespaces would allow a much smoother transition from an extension to an official module. This is a natural path of evolution to make sure XLIFF can evolve to met future needs. I think Paul Leahy was mentioning the evolutive aspect of 2.0 in one of his XLIFF-relation presentations as a key point of the new version.

- Projects like MultilingualWeb-LT are working on many data categories that are related to localization process. That is just one example. The point is: XLIFF does not work in a vacuum, and 2.0 needs to be flexible enough to take into account other standards that are relevant. Namespaces are the perfect mechanism for this.


So, overall, I think something like meta-holder is mostly based on the false premise that it will solve the use of bad extensions. And, when you take into account the existing namespace-based modularity of 2.0, custom namespaces are a far better solution for extensions used correctly.

Cheers,
-yves