Philosophical Goal for XLIFF: design for the "lowest commondenominator"

[<bryan.s.schnabel@tektronix.com>]

Hello,

I have what might turn out to be a controversial idea. In our efforts to improve XLIFF I think we should consider XML processing to be the "lowest common denominator" when establishing requirements. And I think this should be explicitly stated as a design goal (perhaps in the charter?). Of course many XLIFF implementations use many different models of processing, but if we keep XML processing in mind when we design different aspects of XLIFF, we will probably ensure that we are not designing anything that could be implementable by some methods, but not others.

For example, we now offer two ways of handling inlines. One is the method I'm on record as disliking, <bpt /> and <ept /> (intentionally represented here as stand-alone empty elements). And the other is with <g>........</g>. If (hypothetically) we eliminated the <g> method, and were only left with the former method, I would see this as an example of an unfriendly method for XML processing (in this case requiring *fake* processing with the deprecated XSLT method of disable-output-escaping). Note, in this case I am not proposing that we eliminate the bpt/ept method, just that we not eliminate the g method. Another example is what I consider to be the current bug in <internal-file>. Since it does not include an extensibility point, on must escape embedded XML files (or resort to CDATA sections, which is actually the same thing).

I am not trying to make a case that XLIFF implementers should use XML processing. I am just saying that if we use XML processing as our "lowest common denominator," we will ensure XLIFF's maximum robustness.

(forgive me for the colloquial use of the phrase *lowest common denominator* - it is a misuse of the term, but I hope a common enough misuse that expresses my meaning)

Thanks,

Bryan