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: FW: [xliff-comment] Xliff 1.2 transitional schema validation behaviour with extended nodes

Hi Tom, and other Schema experts,


I don’t think anyone has answer the question below that posted on the comments list.

Maybe that is something we need to check to make sure it does not occurs in 2.0.





From: Abad, Alberto [mailto:aabad@ea.com]
Sent: Wednesday, August 7, 2013 2:38 PM
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




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

<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2"  xmlns:ext="urn:extended" version="1.2">

  <file source-language="en-US" target-language="de-DE" datatype="plaintext" original="not.available">


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

        <source>I18n and L10n</source>

        <target>Internationalisierung und Lokalisierung</target>




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



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.





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

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