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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Arle,

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

Not sure if I understand: XLIFF elements "can" support only what they are designed for. Anything else would be extensions. In other words: all use cases of extension should be cases of things the XLIFF specification does not provide for.


> 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?

Isn't a "filterable payload" the same thing as an extension: something that you add to the XLIFF document, and that XLIFF processors not knowing about it just pass through.

I think we need to be strict: If something "would not work with XLIFF core"--which I read: "would prevent an XLIFF tool to work properly"--then it shouldn't be in an XLIFF document. A tool implementing only the core should always be able to do its job regardless what optional modules or extensions are in the document.

Cheers,
-yves