OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
  • 1.  Unique Particle Attribution issue in matches.xsd

    Posted 01-14-2014 23:45
    Hi Tom, Bryan, and other XSD experts, In the matches.xsd file we have this: <xs:element name="match"> <xs:complexType> <xs:sequence> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:target"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:originalData"/> <xs:element minOccurs="0" maxOccurs="1" ref="mda:metadata"/> <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/> The file seems to work fine in oXygen, but when I try to use it with Xeres validators I'm getting: java.lang.RuntimeException: Cannot load the XLIFF 2.0 schema. Reason: cos-nonambig: "urn:oasis:names:tc:xliff:document:2.0":originalData and WC[##other:"urn:oasis:names:tc:xliff:matches:2.0"] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. at net.sf.okapi.lib.xliff.reader.SchemaValidator.validate(SchemaValidator.java:72) This is the same issue we had before in the core. Any idea how to address it here? I suppose we can just comment out xlf:originalData and mda:metaData and list them in the specification. A side note: If I recall correctly Chet mentioned that when specification and schema had a discrepancy the schema had the final word. How does it work with XLIFF 2.0? Clearly the schemas are limited now and do not represent the full intend of the specification (I'm talking in general, not about the specific case above). Cheers, -yves


  • 2.  RE: [xliff] Unique Particle Attribution issue in matches.xsd

    Posted 01-15-2014 04:43
    One alternative to removing originalData and metadata is to place source or target (or both) just before the extension point. Both of those elements are required, so it resolves the ambiguity.


  • 3.  Re: [xliff] Unique Particle Attribution issue in matches.xsd

    Posted 01-15-2014 10:14
    I think that this is what we should do, this was also possible for core, yet the TC decided for various business reasons not to do this in core. However, I believe that the Constraint solution an overkill for a module. Let us just reorder them as Tom proposes and the ambiguity will be resolved. I'd keep source and target together, seems to make more sense Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Wed, Jan 15, 2014 at 4:44 AM, Tom Comerford < tom@supratext.com > wrote: One alternative to removing originalData and metadata is to place source or target (or both) just before the extension point. Both of those elements are required, so it resolves the ambiguity.