/!\ The following content is an initial draft and may not represent the view of the XLIFF TC.

This document records all known errors in the XLIFF 1.2 Specification (Oasis Standard 1 February 2008).

1. <xliff> element definition

Applies to: Schema

1.1. Description

The <xliff> element contents description is defined as:

This is represented in the schema as:

<xsd:element name="xliff">
  <xsd:complexType>
    <xsd:sequence maxOccurs="unbounded">
      <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
      <xsd:element ref="xlf:file"/>
    </xsd:sequence>
    ... attributes ...
  </xsd:complexType>
</xsd:element>

Notice:

  1. The sequence is switched around, so you have to end with a <file> element, hence invalidating the "followed by zero, one or more non-XLIFF elements" statement.

  2. This definition allows for mixing any number of <file> and other-namespace elements, as long as you end with a <file> element. This representation allows much more than the specification.

1.2. Recommendations

The schema definition is changed to:

<xsd:element name="xliff">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element ref="xlf:file" maxOccurs="unbounded" minOccurs="1" />
      <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
    </xsd:sequence>
    ... attributes ...
  </xsd:complexType>
</xsd:element>

1.3. References

2. <tool> element definition

Applies to: Schema

2.1. Description

The <tool> element contents description is defined as:

This is represented in the schema as:

<xsd:element name="tool">
  <xsd:complexType mixed="true">
    <xsd:sequence>
      <xsd:any namespace="##any" processContents="strict" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
    ... attributes ...
  </xsd:complexType>
</xsd:element>

Notice:

  1. the mixed="true" attribute which doesn't belong there.

  2. the namespace="##any" attribute. This should be namespace="##other to be consistent with the rest of the specification.

2.2. Recommendations

The schema definition is changed to:

<xsd:element name="tool">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:any namespace="##other" processContents="strict" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
    ... attributes ...
  </xsd:complexType>
</xsd:element>

Change made ONLY to the STRICT schema to remain compatible with the XLIFF 1.1 schema.

2.3. References

3. <alt-trans> element definition

Applies to: Schema

3.1. Description

The Content description for the <alt-trans> element is defined as:

Followed by this statement:

The schema definition for <alt-trans>:

<xsd:element name="alt-trans">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element minOccurs="0" ref="xlf:source"/>
      <xsd:element minOccurs="0" ref="xlf:seg-source"/>
      <xsd:element maxOccurs="unbounded" ref="xlf:target"/>
      <xsd:element maxOccurs="unbounded" minOccurs="0" ref="xlf:context-group"/>
      <xsd:element maxOccurs="unbounded" minOccurs="0" ref="xlf:prop-group"/>
      <xsd:element maxOccurs="unbounded" minOccurs="0" ref="xlf:note"/>
      <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="skip"/>
    </xsd:sequence>
    ... attributes ...
  </xsd:complexType>
  ...
</xsd:element>

Note that the schema does indeed enforce the order of <context-group>, <note> and <prop-group> elements.

3.2. Recommendations

The schema definition is changed to:

<xsd:element name="alt-trans">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element minOccurs="0" ref="xlf:source"/>
      <xsd:element minOccurs="0" ref="xlf:seg-source"/>
      <xsd:element maxOccurs="1" ref="xlf:target"/>
      <xsd:choice maxOccurs="unbounded" minOccurs="0">
        <xsd:element ref="xlf:context-group"></xsd:element>
        <xsd:element ref="xlf:prop-group"></xsd:element>
        <xsd:element ref="xlf:note"></xsd:element>
      </xsd:choice>
      <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="strict"/>
    </xsd:sequence>
    ... attributes ...
  </xsd:complexType>
  ...
</xsd:element>

Change made ONLY to the TRANSITIONAL schema to become compatible with XLIFF 1.0. The XLIFF 1.1 schema is NOT compatible with XLIFF 1.0. Strict schema enforces order as recommended by specification.

3.3. References

4. count-type attribute definition

Applies to: Schema

4.1. Description

The specification defines the following union of allowed values for the count-type attribute:

  1. CountType value list

  2. Xtend values

  3. datatype value list

  4. restype value list

  5. state value list

The XML schema defines the count-type value as follows:

<xsd:simpleType name="AttrType_count-type">
  <xsd:union memberTypes="xlf:restypeValueList xlf:count-typeValueList xlf:datatypeValueList xlf:stateValueList xlf:state-qualifierValueList xlf:XTend"/>
</xsd:simpleType>

Notice that the schema allows state-qualifier values, but not the specification.

4.2. Recommendations

Removed xlf:state-qualifierValueList from AttrType_count-type.

<xsd:simpleType name="AttrType_count-type">
  <xsd:union memberTypes="xlf:restypeValueList xlf:count-typeValueList xlf:datatypeValueList xlf:stateValueList xlf:XTend"/>
</xsd:simpleType>

Change made ONLY to the STRICT schema to remain compatible with the XLIFF 1.1 schema.

4.3. References

5. Section 2.5.1 and 2.5.2

Applies to: Specification

5.1. Description

Section 2.5.1:

The <body>-element is missing in the example XLIFF code.

The example schema in this section won't work this way in conjunction with the previous example. Attribute targetNamespace should read targetNamespace="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1" instead of targetNamespace="XLFSup-v1". Furthermore line xmlns:sup="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1" should read xmlns="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1" as prefix "sup" is not used in the schema.

Section 2.5.2:

The <body>-element is missing in the example XLIFF code, too.

5.2. Recommendations

Corrected example in 2.5.1:

<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2" xmlns:sup="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1 s2-5-1.xsd">
  <file original="passus-1.doc" source-language="enm" datatype="plaintext">
    <body>
      <group>
        <sup:SourceInfo>
          <sup:Book>Piers Plowman, Passus 1</sup:Book> <sup:Author>William Langland</sup:Author>
        </sup:SourceInfo>
        <sup:WorkInfo Task="transcription" Context="Middle-English:1360"/> 
        <trans-unit id="1">
          <source xml:lang="enm">What this mountaigne bymeneth</source> 
          <target xml:lang="en">What this mountain means</target>
          <sup:Reference Type="strophe">1-a</sup:Reference>
        </trans-unit>
        <trans-unit id="2">
          <source xml:lang="enm">and the merke dale</source>
          <target xml:lang="en">and the dark dale</target> 
          <sup:Reference Type="strophe">1-b</sup:Reference>
        </trans-unit> 
        <trans-unit id="3">
          <source xml:lang="enm">And the feld ful of folk</source>
          <target xml:lang="en">And the field full of folk</target>
          <sup:Reference Type="strophe">2-a</sup:Reference>
        </trans-unit>
        <trans-unit id="4">
          <source xml:lang="enm">I shal yow faire shewe.</source>
          <target xml:lang="en">I fairly will show.</target>
          <sup:Reference Type="strophe">2-b</sup:Reference>
        </trans-unit>
       </group>
    </body>
  </file>
</xliff>

Corrected schema in 2.5.1:

<xsd:schema targetNamespace="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xsd:element name="SourceInfo">
    <xsd:complexType>
      <xsd:sequence maxOccurs="unbounded">
        <xsd:element name="Book" type="xsd:string"/> <xsd:element name="Author" type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element> 
  <xsd:element name="WorkInfo">
    <xsd:complexType>
      <xsd:attribute name="Task" type="xsd:string"/>
      <xsd:attribute name="Context" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="Reference">
    <xsd:complexType>
      <xsd:simpleContent>
        <xsd:extension base="xsd:string">
          <xsd:attribute name="Type" type="xsd:string"/>
        </xsd:extension>
      </xsd:simpleContent>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Corrected example in 2.5.2:

<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2" xmlns:htm="http://www.w3.org/1999/xhtml">
  <file original="table.htm" source-language="en" datatype="html">
    <body>
      <group restype="table" htm:border="1" htm:cellpadding="5" htm:cellspacing="0" htm:width="100%">
        <group restype="row">
          <trans-unit id="1" htm:valign="top" htm:width="30%">
            <source>Text of row 1 column 1</source>
          </trans-unit> 
          <trans-unit id="2" htm:valign="top" htm:width="30%">
            <source>Text of row 1 column 2</source>
          </trans-unit>
        </group>
        <group restype="row">
          <trans-unit id="3" htm:valign="top" htm:width="30%">
            <source>Text of row 2 column 1</source>
          </trans-unit>
          <trans-unit id="4" htm:valign="top" htm:width="30%">
            <source>Text of row 2 column 2</source>
          </trans-unit>
        </group>
      </group>
    </body>
  </file>
</xliff>

5.3. References

6. count-group and count

Applies to: Schema

6.1. Description

According to specification content of a <count-group> element consists of "One or more <count> elements". The schema allows zero <count> elements, too.

According to specification in element <count> the attribute "count-type" is required. However, it is optional in the schema.

6.2. Recommendations

Corrected schema:

<xsd:element name="count-group">
  <xsd:complexType>
    <xsd:sequence maxOccurs="unbounded">
      <xsd:element ref="xlf:count"></xsd:element>
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required"></xsd:attribute>
  </xsd:complexType>
</xsd:element>
<xsd:element name="count">
  <xsd:complexType>
    <xsd:simpleContent>
      <xsd:extension base="xsd:string">
        <xsd:attribute name="count-type" type="xlf:AttrType_count-type" use="required"></xsd:attribute>
        <xsd:attribute name="phase-name" type="xsd:string" use="optional"></xsd:attribute>
        <xsd:attribute default="word" name="unit" type="xlf:AttrType_unit" use="optional"></xsd:attribute>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
</xsd:element>

6.3. References

7. Conformance Clauses

Applies to: Specification

7.1. Description

The OASIS TC Process requires that all specifications must include a separate section that lists a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof).

Conformance guidelines documents are available at: http://www.oasis-open.org/apps/org/workgroup/ioc/download.php/305/conformance_requirements-v1.pdf

7.2. Proposed Draft

XLIFF is an XML vocabulary, thereafter conformant XLIFF documents MUST be well formed and valid XML documents.

Conformant XLIFF documents MUST be valid instances of at least one of the official XML Schemas (Strict or Transitional) that are part of the XLIFF specification. As not all aspects of the XLIFF specification can be expressed in terms of XML Schemas, conformant XLIFF documents MUST also comply with all requirements indicated in section 3 of the specification document.

Applications that generate XLIFF documents MUST generate conformant XLIFF documents to be considered XLIFF compliant.

XLIFF documents MAY contain custom extensions, as defined in section 2.5 (Extensibility). Applications that process conformant XLIFF files that contain custom extensions are not required to understand and process non-XLIFF elements or attributes. However, conformant applications SHOULD preserve existing custom extensions when processing conformant XLIFF files.

XLIFF is a format explicitly designed for exchanging data. Thus, a conformant XLIFF application MUST be able to accept XLIFF files it generated after those XLIFF files have been processed by a different tool, provided that: a) processed files are conformant XLIFF documents and b) any custom extension added by the originating tool has been preserved.

7.3. References

8. Errata Title

Applies to: Schema, Specification

8.1. Description

(A brief description of the issue)

8.2. Recommendations

(Recommended approaches)

8.3. References

XLIFF1.2/Errata (last edited 2009-08-12 18:07:06 by localhost)