OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi all,

Very interesting discussion today. Hopefully we can continue on the mailing list.

May be there are different aspects to to consider in "compliance".

I agree with Rodolfo that for conformance we can only talk about the document. XLIFF has a specification, along with a schema, and a document is or not conformant to those. No tools involved. And applications like XLIFFChecker can hopefully check that conformance.

But that is only one facet of the compliance problem.

I don't think OASIS has a formal way to handle the other facet: processing expectations.
And to me that is where the biggest interoperability issue resides.
Users don’t care if their document is conformant, they care if their tools can read it, work with it, and generates back a file that the initial tool can be happy with.

This usually translate into being able to ascertain that a tool uses the proper XLIFF construct to act on a given aspect of the document.

For example, in 1.2, there is a translate="yes/no" attribute that indicates if the trans-unit content needs to be translated or not. I would expect a "XLIFF-compliant" tools to use that attribute to both indicate that status of a trans-unit (when generating XLIFF), and to read that information when sorting out what is translatable or not in the file (when loading XLIFF).

There has to be ways to prescribe those processing expectations in the standard. We are not in the conformance aspect anymore, I agree. But this facet is as important to XLIFF as document conformance is, otherwise we will keep having documents that are not really seamlessly useable for exchange, because the tools pick and choose how they work with the standard.

I don't know how that can be achieved. I think having a much more modular XLIFF and stricter modules (e.g. less attr="x-whatever") could help. It is a difficult problem, because we need to make sure while the format is more strict, the tools still have ways to implement things how it works best for them.
I feel certain this is an aspect we have to tackle to have a XLIFF 2.0 that "really works".

Cheers,
-ys

Hi,

Interoperability has two outstanding aspects:

1) Compliance of XLIFF documents.
2) Compatibility in processing.

With the conformance clause we can set the rules that deal with documents and their validity.

Processing expectations should be included in the specification, next to each feature. But we need coherency in the specification.

Yves' example of support for the "translate" attribute is interesting. You can set the value of this attribute in 

> We can avoid this problem by stating some rules in the 
> specification, something along these lines but not 
> necessarily this:
>       "When generating the final document, the value of 
>       the "approved" attribute must be considered. If its
>       value is "yes", use the translations provided in 
>       the