Re: [xliff] Complex XLIFF/ITS example and problems with Schematron valid

as for the issue with the schematron rule processing annotatorsRef, I fixed this in the following away: duplicates of data category identifiers are now checked. In addition I removed the below rule, since alphabetic ordering is not required by annotatorsRef.

<!--
  <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:value-of select="$ids-string"/>
  </sch:assert>—>

From my view, in the Schematron file, the only missing item is the processing of the frag-ids with the XLIFF prefix.

Best,

Felix

Am 03.04.2017 um 13:29 schrieb David Filip <david.filip@adaptcentre.ie>:

Yes, it is an XLIFF specific, yet it doesn't prevent parsing by native ITS processors, so it's OK

Dr. David Filip
===========
OASIS XLIFF OMOS TC Chair
OASIS XLIFF TC Secretary, Editor, Liaison Officer
Spokes Research Fellow
ADAPT Centre
KDEG, Trinity College Dublin
Mobile: +420-777-218-122

On Mon, Apr 3, 2017 at 11:56 AM, Felix Sasaki <felix@sasakiatcf.com> wrote:

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 Provenance

OK. That constraint for locQualityIssueRef then will be XLIFF specific, see the remark above.

Best,

Felix

On 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,

Felix

Am 03.04.2017 um 11:58 schrieb David Filip <david.filip@adaptcentre.ie>:

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>:

Hi Felix, all,

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
http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html
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  <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//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  <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 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 <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 <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

xliff message