Re: [xliff] Clarification needed for annotatorsRef

Hi Yves, all,

my XSLT implementation does not do Validation of the annotatorsRef
attribute. The implementation processes annotatorsRef per data category and
takes the inheritance of annotatorsRef into account, that is it. So I did
not run into the problem. But the suggestion

“ascii-U+0020-space-separated”

sounds good to me.

Cheers,

Felix



2017-05-13 14:04 GMT+02:00 Yves Savourel <ysavourel@enlaso.com>:

> Hi all,
>
>
>
> While looking at the ITS module for XLIFF, a question came up with regards
> to how the annotatorsRef value is specified.
>
>
>
> The Schematron rule for ITS assumes the “space-separated” in the
> definition of the annotatorsRef value means “whitespace-separated”. But the
> text is not specific (See https://www.w3.org/TR/its20/#its-tool-annotation:
> “The value of annotatorsRef is a space-separated list of references where
> each reference is composed of two parts: a data category identifier and an
> IRI. These two parts are separated by a | VERTICAL LINE (U+007C) character”)
>
>
>
> The current Okapi implementation of the ITS processor assumes just
> “ascii-U+0020-space-separated” and since none of the files in the ITS2.0
> test suite tests this, we have not run into the question so far.
>
>
>
> The change would be easy enough to make but I wanted to know what other
> implementations are doing.
>
>
>
> Thanks,
>
> -yves
>
>
>
>
>
> *From:* xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] *On
> Behalf Of *Yves Savourel
> *Sent:* Saturday, May 13, 2017 5:24 AM
> *To:* 'XLIFF Main List' <xliff@lists.oasis-open.org>
> *Subject:* RE: [xliff] Invalid ist:annotatorsRef in example
>
>
>
> Actually this means the formatted example 23 in the ITS spec incorrect as
> well:
>
>
>
> In the printout https://www.w3.org/TR/2013/REC-its20-20131029/#its-tool-
> annotation
>
> And in the file itself: https://www.w3.org/TR/2013/
> REC-its20-20131029/examples/xml/EX-its-tool-annotation-2.xml
>
>
>
> It is strange that the ITS validator didn’t catch the issue.
>
>
>
> Maybe this rule is incorrect?
>
>
>
> <assert test="every $ref in tokenize(@its:annotatorsRef, '\s+') satisfies
>
>         matches($ref, '
>
>         (translate|localization-note|terminology|directionality|
> language-information|
>
>         elements-within-text|domain|text-analysis|locale-filter|
> provenance|external-resource|
>
>         target-pointer|id-value|preserve-space|localization-
> quality-issue|localization-quality-rating|
>
>         mt-confidence|allowed-characters|storage-size)\|.+')">
>
>         The value of annotatorsRef is a space-separated list of references
> where
>
>         each reference is composed of two parts: a data category
> identifier and an IRI.
>
>         These two parts are separated by a character | VERTICAL LINE
> (U+007C).</assert>
>
>
>
> Shouldn’t the “storage-size)\|.+'” part disallow white-space after ‘|’?
>
>
>
> Or should we allow white-space on the right side of the ‘|’? (which does
> not seem to be correct based on the text describing the value).
>
>
>
>
>
> *From:* xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org
> <xliff@lists.oasis-open.org>] *On Behalf Of *Yves Savourel
> *Sent:* Saturday, May 13, 2017 5:07 AM
> *To:* XLIFF Main List <xliff@lists.oasis-open.org>
> *Subject:* [xliff] Invalid ist:annotatorsRef in example
>
>
>
> In the big example of section 5.9.13, I think there are several
> annotatorsRef values that are invalid.
>
> For example:
>
>
>
> <file id="f1" its:annotatorsRef="allowed-characters|
>
>       http://example.com/myAllowedCharactersAnnotationTool terminology|
>
>       http://example.com/mytermTool localization-quality-issue|
>
>       http://example.com/anotherQualityChecker">
>
>
>
> Is wrapped after the “|” but since space is the separator for references
> that breaks the reference (and creates empty ones).
>
>
>
> The valid wrapped notation would be:
>
>
>
> <file id="f1" its:annotatorsRef="allowed-characters|http://example.com/
> myAllowedCharactersAnnotationTool
>
>       terminology|http://example.com/mytermTool
>
>       localization-quality-issue|http://example.com/anotherQualityChecker
> ">
>
>
>
> Cheers,
>
> -yves
>
>
>
> Yves Savourel
> Localization Solutions Architect | ENLASO®
> 4888 Pearl East Circle | Suite 300E | Boulder | Colorado 80301
> t: 303.945.3759 | f: 303.516.1701
> An ISO 9001:2015 certified company
>
>
>
> *Confidentiality Notice*
> The information in this transmittal may be privileged and confidential and
> is intended only for the recipient(s) listed above. Any review, use,
> disclosure, distribution or copying of this transmittal, in any form, is
> prohibited except by or on behalf of the intended recipient. If you have
> received this transmittal in error, please notify me immediately by reply
> email and destroy all copies of the transmittal.
>
>
>