RE: Xliff 1.2 transitional schema validation behaviour with extended nod

And now I see I did not supply the link to the TC thread. It is here https://lists.oasis-open.org/archives/xliff/201308/msg00062.html

From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com]
Sent: Monday, August 19, 2013 2:27 PM
To: Abad, Alberto; xliff-comment@lists.oasis-open.org
Cc: Eng R&D Team @ IDS
Subject: [xliff-comment] RE: Xliff 1.2 transitional schema validation behaviour with extended nodes

Hello Alberto Abad,

Thank you for raising this issue. And please accept my apology that I allowed nearly two weeks to pass before addressing your concern.

We looked into this and verified your assertion that the schema and the spec are contradictory. I’ve attached a snip that explains this, from our schema editor, Tom Comerford (btw, this explanation is available in full on the TC’s public mailing list ).

The documentation for the <xliff> element says:

One or more <file> elements, followed by

Zero, one or more non-XLIFF elements.

while the schema says:

<xsd:sequence maxOccurs="unbounded">

<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>

<xsd:element ref="xlf:file"/>

</xsd:sequence>

I also checked with our OASIS TC Administrator. He said that in a situation like this when the spec and schema disagree, the schema’s interpretation is authoritative. He noted that the TC Process sect 2.18 states "All normative computer language definitions must be provided in separate plain text files... Where any definition in these separate files disagrees with the definition found in the specification, the definition in the separate file prevails."

The good news is we are in the process of releasing XLIFF 2.0. Tom has scripts in place that will ensure the spec and schema are in synch (details in the tread I mentioned above).

Thank you very much for pointing the contradiction out to us.

Please feel free to ask further questions if you have them.

Thanks,

Bryan

From: Abad, Alberto [mailto:aabad@ea.com]
Sent: Wednesday, August 07, 2013 5:38 AM
To: xliff-comment@lists.oasis-open.org
Cc: Eng R&D Team @ IDS
Subject: [xliff-comment] Xliff 1.2 transitional schema validation behaviour with extended nodes

Hi,

While doing tests for a service we’re building for translation of xliff files, we found an strange behaviour of the xliff 1.2 transitional schema for validation using an xliff with an extended element right after the <file> one, an example:

<?xml version="1.0" encoding="utf-8"?>

<body>

<trans-unit id="1" resname="I18n and L10n">

<target>Internationalisierung und Lokalisierung</target>

</trans-unit>

</body>

</file>

<ext:custom>Extended stuff</ext:custom>

</xliff>

Above file fails validation against xliff 1.2 transitional schema with the following messages:

· From .NET code: “System.Xml.Schema.XmlSchemaValidationException: The element 'xliff' in namespace 'urn:oasis:names:tc:xliff:document:1.2' has incomplete content. List of possible elements expected: 'file' in namespace 'urn:oasis:names:tc:xliff:document:1.2' as well as any element in namespace '##other'.”

· From the XLIFFChecker tool: “[Error] 12:9 cvc-complex-type.2.4.b: The content of element 'xliff' is not complete. One of '{WC[##other:"urn:oasis:names:tc:xliff:document:1.2"], "urn:oasis:names:tc:xliff:document:1.2":file}' is expected.”

The strange thing is that if we take the same file and swap the order of the <file> and the extended elements (ie, first <ext:custom> element, then <file> one) it successfully validates according to the transitional schema, even though the element order, according to the documentation, is the opposite (ie, the element order of example above that doesn’t validate).

Apparently it seems to be a bug in the schema or a mismatch between the schema and documentation, as according to the documentation the examples above should either have opposed validation results (if order is enforced) or on the contrary both validate successfully (if order is not enforced).

PD: We got the xsd for the transitional schema from the schema section of the documentation.

PD2: We have a sample VS2010 solution with tests reproducing above scenarios, but have not attached it to avoid spamming the whole dist list; please feel free to ask for it in the event it helps clarifying.

Regards,

AAB

Electronic Arts Software S.L., Calle Via de los Poblados 3, Edificio 3, 28033 Madrid, Registered Number: 0A714779, Spanish Co. but Portuguese VAT Reg., VAT-Id-no.= PT 980 179 041, Spanish VAT Reg,VAT-Id-no.= ES B81009151

xliff-comment message