[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
Am 03.04.2017 um 12:17 schrieb David Filip <david.filip@adaptcentre.ie>:The Schematron rule needs to catch up with prose. That's part of issue 45.Since the ..ref attribute is from the W3C namespace, it has to have the same data type as in the ITS spec. Not sure if it's IDREF or IRI.For locQualityIssueRef the data type is IRI. Resolving the reference does not put a constraint on the location of the standoff markup, e.g. it can be outside the current file.It's worth checking in the prose and rules for both Quality Issues and Provence referencing.Disregarding which mechanism, there will be still a Constraint and rule saying that the referenced element must be in the same unit for Quality Issue, in the same unit / group / file for ProvenanceOK. That constraint for locQualityIssueRef then will be XLIFF specific, see the remark above.Best,FelixOn Apr 3, 2017 12:04, "Felix Sasaki" <felix@sasakiatcf.com> wrote:Hi David, Yves, all,Yves wrote"Shouldn’t the its:locQualityIssuesRef attribute use a URI? It seems the example uses just an ID value."if we use an URI we should have „#“ at the start. If I do that I get an validation error:"The value of the locQualityIssuesRef attribute must be an NMTOKEN value of one of the id attributes declared on a <locQualityIssues> elements within the same 'unit'.„It seems that the related schematron rule, which changes for identity of values, is borken, since a locQualityIssues element could be anywhere and is to be referenced with a URI, as Yves pointed out. So we should probably drop that Schematron rule.Best,FelixAm 03.04.2017 um 11:58 schrieb David Filip <david.filip@adaptcentre.ie>:We didn't change Namespace versions for core and old modulesOn Apr 3, 2017 11:57, "David Filip" <david.filip@adaptcentre.ie> wrote:Version on <xliff> must be 2.1Namespace version is still 2.0On 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:xlif f:document:2.0“? About the version: agree. Abou the namespace: Loking atit seems to be „2.0“, not „2.1“. Not sure which one is correct.Best,FelixCheers,-yvesYves 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 validationHi 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:locQualityIssuesRelated 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//i ts:locQualityIssues[@id=$id] | ancestor::xlf:unit//its:proven anceRecords[@id=$id])"/>
<sch:assert test="$counter=1">
Value of 'id' must be unique among all of <locQualityIssues> and <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//i ts:locQualityIssues[@xml:id=$i d] | ancestor::xlf:unit//its:proven anceRecords[@xml:id=$id])"/>
<sch:assert test="$counter=1">
Value of 'id' must be unique among all of <locQualityIssues> and <provenanceRecords> elements within the enclosing 'unit'. Value: <sch:value-of select="$id"/>
</sch:assert>
</sch:rule>
</sch:pattern>2) Testing of ID in LQI standoffRelated schematron pattern:<sch:pattern><sch:rule context="xlf:mrk[@its:locQualityIssuesRef] | xlf:sm[@its:locQualityIssuesRe f]">
<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:locQuality Issues[@id=current()/@its:locQ ualityIssuesRef])=1">
The value of the locQualityIssuesRef attribute must be an NMTOKEN value of one of the id attributes declared on a <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:locQualityIssuesRe f]">
<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:locQuality Issues[@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 <locQualityIssues> elements within the same 'unit'.
</sch:assert>
</sch:rule>
</sch:pattern>3) Namespace qualified attributes at standoff elementsits.xsd issue: the following defines namespace qualified attributes, but they should be unqualified<xs:element name="locQualityI
ssue">
<xs:complexType mixed="false">
<xs:attribute ref="its:locQualityIssueType" use="optional" />
<xs:attribute ref="its:locQualityIssueComment" use="option al"/>
<xs:attribute ref="its:locQualityIssueSeverity" use="optio nal"/>
<xs:attribute ref="its:locQualityIssueProfileRef" use="opt ional"/>
<xs:attribute ref="its:locQualityIssueEnabled" use="option al"/>
</xs:complexType>
</xs:element>Fix:<xs:element name="locQualityIs
sue">
<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="option al"/>
<xs:attribute name="locQualityIssueEnabled" use="optional" />
</xs:complexType>
</xs:element>Same issue for provenanceRecords - fix:<xs:element name="provenanceR
ecord">
<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 annotatorsRefThe below rule detects errorr which are none<sch:pattern>
<sch:rule context="xlf:*[@its:annotatorsRef][(contains(@it s: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-value s($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*(dir ectionality)?\s*(domain)?\s*(e lements-within-text)?\s*(exter nal-resource)?\s*(id-value)?\s *(language-information)?\s*(lo cale-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]