RE: [xliff] Definition of "core" and "modules"

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

I generally agree with Rodolfo's wording.
And see no issue in Arle's text suggestions.


Just one note on a side topic that Arle and Rodolfo touched on.
(should probably go to a different thread):

>> Can we change “that belong to a module” to “that belong 
>> to officially recognized modules”? We don't want anything 
>> that might appear to obligate us to include private 
>> modules in an annex to XLIFF 2.0. While I would hope 
>> people would document their modules publicly, we cannot 
>> make them do so.
>
> There will not be private modules. We agreed some time 
> ago to drop extensibility.

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.


> Those companies that created custom extensions had a chance 
> to submit their schemas and documentation for analysis 
> so we can contemplate their needs in XLIFF 2.0. So far 
> we received several schemas but no documentation. It 
> is not easy to consider particular needs when creating 
> a draft schema for XLIFF 2.0 if interested parties don't 
> provide information.

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

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.

I totally agree with requiring that features existing in XLIFF must be use over extensions, always. But if XLIFF does not provide for that feature there is no reason to not allow the extension.

I also understand the danger that allowing extension does open the door to abuse. 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.

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.

Cheers,
-yves