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
