RE: [xliff] Extensibility

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo, all,

> ...Badly used extensibility is what we have today.

Just for the record: We don't have *only* bad extensions in v1.2. I've seen quite a few that are perfectly fine: They are representing features not in the specifications and are not preventing tools which don't know about them to work properly.


> Extensions are not mainly used to overcome shortcomings 
> in the spec as you say. They are used to hold data 
> that the specification already handles well.

That's why I was saying: "...having extensibility in XLIFF is fine. But: a) they should not be used for duplicating features that already exist in XLIFF..."


> We have three basic options for dealing with extensibility:
> 1) Forbid custom extensions; 
> 2) Allow extensibility without restrictions, as happens today;
> 3) Allow extensibility with clear regulations.
> Option 2) is what users don't like. 

We do agree: It's not that "users think that extensibility is bad for XLIFF", it's just that they want extensions to be used properly.


> We don't have a set of well written regulations for 
> opting for option 3) yet.
> Unless we get a really good proposal for regulating 
> extensibility, the only choice left is 1).

Option 1 is "forbid custom extensions", yet you are proposing along with Bryan a <metaHolder>/<meta> mechanism that is a way to define custom extensions. For example nothing would prevent a tool to store match quality information there.

I absolutely agree we do need clear and strict rules on how to use extensions, but that is regardless what our mechanism for extension is (i.e. using <meta> or custom namespaces).


> I'm looking forward to your email on implementing 
> extensions the right way. I hope your proposal helps 
> eliminating current bad practices.

I'm looking forward to your and Bryan's proposal on exactly that too, since you are proposing a custom extension mechanism :)

For example how do we prevent tools to use <metaHolder>/<meta> to store quality match in there?

Whatever the rules are, they can be applied with either <metaHolder>/<meta> or custom namespaces.

So here is a start:

- Extensions MUST not be used to represent existing XLIFF features.

- Extensions MAY be placed in the following locations: <here goes the list of allowed extension points TBD>.

- Extensions SHOULD have a corresponding public schema that can be used for documentation and validation.

- User agents MUST skip the validation of un-documented extensions.


Cheers,
-yves