To extend or not to extend. Was: [xliff] Definition of "core" and "modules"

[Arle Lommel <alommel@gala-global.org>]

> I don't remember any formal vote on the topic of allowing or not extension in 2.0.
> My understanding has been that it was one possibility, but not a decision. But I may have missed something.

If there was a formal decision, it may have happened while I was out of the committee, so I probably missed it as well.

> I agree, but I'm not sure that justify dropping extensions: We simply cannot think about all features XLIFF may need.

That's the reason for my example about gaming. Right now there is an effort afoot (in ETSI, but independent of the new LIS ISG) to create a standard for representing variable text such as that used in gaming. It would be useful to allow their (eventual) results to be represented in XLIFF format, but they cannot contribute their requirements yet because they don’t know them. The ideal approach would be for them to contribute them as a module in the future, but I'm not sure that such a module would not violate some of our principles if it could not be processed as a core-only document.

> The problem is not the extensions. The issue is that some extensions that are used to represent things that already exists in XLIFF, breaking interoperability.

They can also be a problem if they add additional functionality that goes beyond core functionality and that keeps the file from being processed. So the issue isn't only about conflict with things that already exist, but also with cases where extensions would be required because processing requirements cannot be handled in a core-only mode without breaking things.

> I totally agree with requiring that features existing in XLIFF must be use over extensions, always.

Agreed.

> But if XLIFF does not provide for that feature there is no reason to not allow the extension.

Would it be possible to provide a mechanism for the registration of private extensions?

> I also understand the danger that allowing extension does open the door to abuse.

There is abuse, as you note, but there are times when companies might want to use XLIFF but find it doesn't quite meet their needs. Forbidding extensions entirely would essentially send the message that XLIFF can only be used in those environments which the committee, in its infinite wisdom, has deemed necessary. But if your use case falls outside of those, you get none of the benefit. I know it's tricky to balance these things, but if we define the modules and disallow extensions, we are simultaneously cutting off some sources of good input.

Obviously we don't want to see “XLIFF Wars” like the “Browser Wars” of the 90s with everyone doing things their own ways, but there is a price for cutting off extensions. What if the specification were to contain a stern warning that the XLIFF format does not officially support any third-party extensions, that you can sue them at your own risk, and that they should be used only when existing mechanisms cannot met requirements, along with a request to submit them to the committee for future work?

> But 2.0 is about also clarifying the specification. This should help a great deal to have tool-makers to be more inclined to avoid extensions when they can.

I think this is true. Given the vagueness of the XLIFF 1.2 specification in many areas, I could see developers using extensions because they don't understand the (undocumented) proper XLIFF way to do things. If 2.0 is clearer and avoids these uncertainties, we would have a specification that would be much easier to implement and much harder to mess up.

> Importantly, we should also set up the same criteria for extension as for the optional modules, like: they should not prevent a tool supporting only the core to work, etc.

In principle, I agree, but I think there are cases where the data contained may go beyond what XLIFF itself can support. Maybe the solution in that case is to require that anything that would not work with XLIFF core be treated as a filterable payload with XLIFF as the transport mechanism, passing through the markup as metamarkup? That might not be a bad approach anyway since any tool that would want to work with that content would need to be specially enabled anyway, and keeping that support separate from the question of XLIFF.

-Arle