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: Re: [xliff] Complex XLIFF/ITS example and problems with Schematron validation


We didn't change Namespace versions for core and old modules 

On Apr 3, 2017 11:57, "David Filip" <david.filip@adaptcentre.ie> wrote:
Version on <xliff> must be 2.1
Namespace version is still 2.0

On Apr 3, 2017 09:40, "Felix Sasaki" <felix@sasakiatcf.com> wrote:
Thanks a lot for the feedback Yves.

Am 02.04.2017 um 13:02 schrieb Yves Savourel <ysavourel@enlaso.com>:

 
A couple of notes:
 
1.   Shouldn’t the its:locQualityIssuesRef attribute use a URI? It seems the example uses just an ID value.


good point. I will change this to start with „#“.

 
2.   Shouldn’t the element <xliff> use version="2.1" and xmlns="urn:oasis:names:tc:xliff:document:2.1" rather than version="2.0" xmlns="urn:oasis:names:tc:xliff:document:2.0“?


About the version: agree. Abou the namespace: Loking at
it seems to be „2.0“, not „2.1“. Not sure which one is correct.

Best,

Felix


 
Cheers,
-yves
 

Yves Savourel 
Localization Solutions Architect
 | t: 303.951.4523 | f: 303.516.1701 | ENLASO®

 
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Felix Sasaki
Sent: Saturday, April 1, 2017 10:21 AM
To: XLIFF Main List <xliff@lists.oasis-open.org>
Subject: [xliff] Complex XLIFF/ITS example and problems with Schematron validation
 
Hi all,
 
I created a complex XLIFF/ITS example, see attachment and the last section of the ITS module. I validated the example file and found several issues in the schematron file its.sch and in its.xsd . See attached updated schemas.
 
1) Testing of uniqueness of IDs for provenanceRecords and its:locQualityIssues
Related schematron pattern:
 

 <sch:pattern>
        <sch:rule context="its:locQualityIssues | its:provenanceRecords[ancestor::xlf:unit]">
            <sch:let name="id" value="@id"/>
            <sch:let name="counter" value="count(ancestor::xlf:unit//its:locQualityIssues[@id=$id] | ancestor::xlf:unit//its:provenanceRecords[@id=$id])"/>
            <sch:assert test="$counter=1">
                Value of 'id' must be unique among all of  &lt;locQualityIssues> and &lt;provenanceRecords> elements within the enclosing 'unit'.
            </sch:assert>
        </sch:rule>
    </sch:pattern>

Issue: the rule should count xml:id, not id attributes. Fix:
 

 <sch:pattern>
        <sch:rule context="its:locQualityIssues | its:provenanceRecords[ancestor::xlf:unit]">
            <sch:let name="id" value="@xml:id"/>
            <sch:let name="counter" value="count(ancestor::xlf:unit//its:locQualityIssues[@xml:id=$id] | ancestor::xlf:unit//its:provenanceRecords[@xml:id=$id])"/>
            <sch:assert test="$counter=1">
                Value of 'id' must be unique among all of  &lt;locQualityIssues> and &lt;provenanceRecords> elements within the enclosing 'unit'. Value: <sch:value-of select="$id"/>
            </sch:assert>
        </sch:rule>
    </sch:pattern>

 
2) Testing of ID in LQI standoff
 
Related schematron pattern:
 <sch:pattern>
        <sch:rule context="xlf:mrk[@its:locQualityIssuesRef] | xlf:sm[@its:locQualityIssuesRef]">
            <sch:report test="@its:locQualityIssueSeverity or @its:locQualityIssueProfileRef or @its:locQualityIssueEnabled">
                If the 'its:locQualityIssuesRef' attribute is declared, the following attributes are not allowd: its:locQualityIssueSeverity, its:locQualityIssueProfileRef, and its:locQualityIssueEnabled".
            </sch:report>
            <sch:assert test="count(ancestor::xlf:unit//its:locQualityIssues[@id=current()/@its:locQualityIssuesRef])=1">
                The value of the locQualityIssuesRef attribute must be an NMTOKEN value of one of the id attributes declared on a &lt;locQualityIssues> elements within the same 'unit'.
            </sch:assert>
        </sch:rule>
    </sch:pattern>
 
Issue: the rule should count xml:id, not id attributes. Fix:
 <sch:pattern>
        <sch:rule context="xlf:mrk[@its:locQualityIssuesRef] | xlf:sm[@its:locQualityIssuesRef]">
            <sch:report test="@its:locQualityIssueSeverity or @its:locQualityIssueProfileRef or @its:locQualityIssueEnabled">
                If the 'its:locQualityIssuesRef' attribute is declared, the following attributes are not allowd: its:locQualityIssueSeverity, its:locQualityIssueProfileRef, and its:locQualityIssueEnabled".
            </sch:report>
            <sch:assert test="count(ancestor::xlf:unit//its:locQualityIssues[@xml:id=current()/@its:locQualityIssuesRef])=1">
                The value of the locQualityIssuesRef attribute must be an NMTOKEN value of one of the id attributes declared on a &lt;locQualityIssues> elements within the same 'unit'.
            </sch:assert>
        </sch:rule>
    </sch:pattern>
 
3) Namespace qualified attributes at standoff elements
 
its.xsd issue: the following defines namespace qualified attributes, but they should be unqualified
 

 <xs:element name="locQualityIssue">
    <xs:complexType mixed="false">
      <xs:attribute ref="its:locQualityIssueType" use="optional"/>
      <xs:attribute ref="its:locQualityIssueComment" use="optional"/>
      <xs:attribute ref="its:locQualityIssueSeverity" use="optional"/>
      <xs:attribute ref="its:locQualityIssueProfileRef" use="optional"/>
      <xs:attribute ref="its:locQualityIssueEnabled" use="optional"/>
    </xs:complexType>
  </xs:element>

Fix:

<xs:element name="locQualityIssue">
    <xs:complexType mixed="false">
      <xs:attribute name="locQualityIssueType" use="optional"/>
      <xs:attribute name="locQualityIssueComment" use="optional"/>
      <xs:attribute name="locQualityIssueSeverity" use="optional"/>
      <xs:attribute name="locQualityIssueProfileRef" use="optional"/>
      <xs:attribute name="locQualityIssueEnabled" use="optional"/>
    </xs:complexType>
  </xs:element>

Same issue for provenanceRecords - fix:

 <xs:element name="provenanceRecord">
    <xs:complexType mixed="false">
      <xs:attribute name="org" use="optional"/>
      <xs:attribute name="orgRef" use="optional"/>
      <xs:attribute name="person" use="optional"/>
      <xs:attribute name="personRef" use="optional"/>
      <xs:attribute name="revOrg" use="optional"/>
      <xs:attribute name="revOrgRef" use="optional"/>
      <xs:attribute name="revPerson" use="optional"/>
      <xs:attribute name="revPersonRef" use="optional"/>
      <xs:attribute name="revTool" use="optional"/>
      <xs:attribute name="revToolRef" use="optional"/>
      <xs:attribute name="tool" use="optional"/>
      <xs:attribute name="toolRef" use="optional"/>
    </xs:complexType>
  </xs:element>

Also the following schematron rule needs to be changed = drop the namespace prefixes

<sch:pattern>
        <sch:rule context="its:provenanceRecord">
            <sch:assert test="@its:org or @its:orgRef or @its:person or 
                @its:personRef or @its:revOrg or @its:revOrgRef or 
                @its:revPerson or @its:revPersonRef or @its:revTool or
                @its:revToolRef or @its:tool or @its:toolRef">
                At least one of the followings must be set: its:org, its:orgRef, its:person, its:personRef, its:revOrg,
                its:revOrgRef, its:revPerson, its:revPersonRef, its:revTool, its:revToolRef, its:tool and its:toolRef.
            </sch:assert>
        </sch:rule>
    </sch:pattern>

4) Errors in annotatorsRef
The below rule detects errorr which are none

<sch:pattern>
        <sch:rule context="xlf:*[@its:annotatorsRef][(contains(@its:annotatorsRef, ' '))]">
            <sch:let name="ids-string" value=" replace(@its:annotatorsRef, '\|\w+','')"/>
            <sch:let name="ids-tokens" value="tokenize($ids-string, ' ')"/>
            <sch:report test="count($ids-tokens)!=count(distinct-values($ids-tokens))">
                Each ITS data category identifier must not be used more than once.
            </sch:report>
            <sch:assert test="matches($ids-string, '^(allowed-characters)?\s*(directionality)?\s*(domain)?\s*(elements-within-text)?\s*(external-resource)?\s*(id-value)?\s*(language-information)?\s*(locale-filter)?\s*(localization-note)?\s*(localization-quality-issue)?\s*(localization-quality-rating)?\s*(mt-confidence)?\s*(preserve-space)?\s*(provenance)?\s*(storage-size)?\s*(target-pointer)?\s*(terminology)?\s*(text-analysis)?\s*(translate)?$')">
                The space separated triples are not ordered alphabetically as per the ITS Data category identifier or contain iligal value. Please see the Specification for guidelines on the value of this attribute..
            </sch:assert>
         </sch:rule>
    </sch:pattern>

 
Best,
 
Felix



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