[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: To extend or not to extend. Was: [xliff] Definition of "core" and "modules"
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