RE: [xliff] Input to discussion on Conformance

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

> -----Original Message-----
> From: Lieske, Christian [mailto:christian.lieske@sap.com]
> Sent: Tuesday, October 26, 2010 8:12 AM
> To: xliff@lists.oasis-open.org
> Cc: Yves Savourel; Rodolfo M. Raya
> Subject: RE: [xliff] Input to discussion on Conformance
> 
> I understand the points you make about the four types of Markup
> Conformance - I would completely agree if the state of existing
> implementations would be different from what was depicted in the
> presentations at the XLIFF Symposium. However, I think - given the current
> state of affairs - the fine grained distinction which I propose is important:
> 
> 	It enables very targeted communication related to conformance. It
> allows providers of XLIFF files and applications to make very targeted
> statements.
> 
> This allows interested parties to clearly figure out if a certain type of
> interoperability already is possible or not. They will be able to figure out
> whether for example a tool chain involving tool A and tool B is viable (e.g.
> since both tools "only" conform to "n-un") - since for example information
> that is carried in extensions will survive/can be utilized.

Hi Christian,

As I see it, you are trying to qualify the conformance of tools and their adequacy to a given category. We cannot afford to do that.
 
What we can do at this moment is publish a program that validates XLIFF files. We can check whether an XLIFF document is valid or not, but we cannot say that tool A conforms to a certain category and, if tool B conforms to the same category, infer anything about their interoperability.
 
Also, we cannot control what the publishers of tools A and B state about the conformance levels of their tools. Their marketing staff will handle that.

Look at what the market offers today. There are tools that use custom extensions and tools that don't use them. I write tools that don't use extensions, but my tools support the extensions from vendor A and don't fully support extensions from vendor B. This means that you cannot classify my tools. However, you can actually evaluate the conformance of the XLIFF files my tools generate. 

Interoperability problems have multiple causes, not only the inclusion of custom extensions. For example, you can have a perfectly valid XLIFF document without custom extensions that uses <bin-unit> elements and not all tools that support XLIFF will be able to handle your file. The classification model you proposed doesn't contemplate this case.

You can find silly interoperability problems that cannot be handled by the proposed categories. Consider the case of a tool that generates XLIFF files that are valid most of the time but cannot read its own XLIFF documents if another program changes the order of attributes in an element. 

If we include classification criteria for XLIFF tools in the conformance section, don't expect tool vendors to indicate the level of conformance of their tools in whatever terms we prescribe in that section. You can find in the market today tools that advertise support for XLIFF and cannot handle the official examples published by this TC. 

Regards,
Rodolfo
--
Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com