OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Conformance / Compliance

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]