RE: [xliff] Conformance clause proposal

["Doug Domeny" <ddomeny@ektron.com>]

My hunch is that the problem isn't so much in making extension schemas public as it is creating them in the first place. If the XLIFF files are not processed with a validation XML parser, then there is little motivation to create the schemas.

Our extension schema is very simple, just a few custom attributes.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; targetNamespace="urn:ektron:xliff" elementFormDefault="qualified">

	<xsd:element name="value">
		<xsd:complexType mixed="true">
			<xsd:attribute name="name" type="xsd:string" use="required"/>
		</xsd:complexType>
	</xsd:element>

	<xsd:attribute name="required" type="xsd:boolean"/>

	<xsd:attribute name="menuid" type="xsd:unsignedLong"/>

	<xsd:attribute name="id" type="xsd:unsignedLong"/>

</xsd:schema>


My frustration has been even being able to perform interoperability testing with the tools. Ektron is a CMS and so we are at the end points: extract and merge. We produce XLIFF documents for the translation tools and then consume translated XLIFF from the tools.

I've been able to do testing with Rodolfo's previous company Heartsome due to its low cost and Rodolfo's excellent responsiveness. We were able to fix a couple of problems.

When we started, Trados was most common, but it wasn't so much an XLIFF tool as it was an XML editor with an XLIFF DTD. It only supported XLIFF 1.0 and the file name extension had to be .xml, not .xlf. Additionally, the XLIFF had to prepopulate the TARGET element--since it was, after all, just an XML editor. My understanding is that SDL Trados no longer has these restrictions. I've not used it, but I did some interoperability testing with SDL last year.

Part of the problem at Ektron is that we are separated from the translator. We sell a product to our customer who then chooses a translator and most likely, the customer doesn't know what tools the translator is using. Even worse, sometimes the translator, if used to working with Word documents and  unaccustomed to translating software, may not be familiar with XLIFF. I've heard of one translator who wanted to charge their client (our customer) extra to reformat the XLIFF into their proprietary format.

Recalling the recent blog discussion on the quality of translation standards, I believe the fault lies in the lack of adoption by the industry as a whole (no vendor in particular) than it does with the standard itself. Interchange standards, by their nature, require at least two companies to cooperate closely. It's an investment not easily made by management comfortable working independently within their existing processes. 

If any tool vendors are willing to perform interoperability testing, please contact me.

Doug

-----Original Message-----
From: Asgeir Frimannsson [mailto:asgeirf@redhat.com] 
Sent: Tuesday, June 01, 2010 7:28 PM
To: Rodolfo M. Raya
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Conformance clause proposal

----- "Rodolfo M. Raya" <rmraya@maxprograms.com> wrote:
> a) The custom XML schemas required to validate the document are
> publicly available.

I am sceptical to this. I don't see why we can't use LAX processing for many of these extensions. What is the use case for forcing implementers to publicly publish these schemas?

Off topic for 'conformance clause', but looking at the ODF specification [1] for inspiration, we should include something like the following to restrict the use of foreign schemas:

"Conforming extended producers should not use foreign elements and attributes for features defined in the OpenDocument specification."

[1] http://docs.oasis-open.org/office/v1.2/part1/cd04/OpenDocument-v1.2-part1-cd04.html#a_21_Document_Processing


cheers,
asgeir

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php