RE: [xliff] Extensibility

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hi Yves,

 

The comments I've read on the first XLIFF Symposium indicate that users think that extensibility is bad for XLIFF. It is not a chimera, just users' perspective that could be short-sighted.

 

Badly used extensibility is what we have today. Implementation is bad, not the mechanism per se.

 

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. I remember a presentation from Yamagata that demonstrates how badly tools are using extensions for holding data, like match quality, that is already contemplated in the specification.

 

It would be nice to include in XLIFF 2.0 all features vendors didn't find in XLIFF 1.2 and covered via custom extensions. The problem we face is that vendors are not really interested in participating in the design of XLIFF 2.0. We don't have actual proposals to overcome those shortcomings in the new version.

 

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

 

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

 

Regards,

Rodolfo

--
Rodolfo M. Raya <RMRAYA@MAXPROGRAMS.COM>
Maxprograms http://www.maxprograms.com

 

 

-------- Original Message --------
Subject: [xliff] Extensibility
From: Yves Savourel <ysavourel@enlaso.com>
Date: Wed, March 21, 2012 8:52 am
To: <xliff@lists.oasis-open.org>

Hi all,

As a first step to continue the discussion on "metadata without extension" I'd like to slay the chimera of "extensibility is bad" once for all.

My understanding is that the community is not opposed to extensibility, it is opposed to bad use of extensions, which is a very different thing.

The real issue is simply that in 1.2 tools are using extensions to overcome the shortcomings of 1.2 and they do it different ways. People complain there are 5 different ways to represent feature XYZ.

The solution is to fix the shortcomings (have one single official way to represent XYZ), not to remove the capability of having extensions. There is nothing wrong with extensions that enhance XLIFF.

In addition I think a large part of the tools vendors are very much in favor of extensibility. That is the only way for them to carry tool-specific data and features. Those are a big part of our community too.


I hope we can, once for all, establish that having extensibility in XLIFF is fine. But: a) they should not be used for duplicating features that already exist in XLIFF. And b) we need to make sure they do not "get in the way".

Now, how to implement extensions is a separate issue.
I'll post a separate email on this since it is a different topic.

Cheers,
-yves


---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org