Yves, Felix, all,
I have created a csprd03 issue from this as this has a potential to cause
changes in our validation, and hence material normative changes.
https://issues.oasis-open.org/browse/XLIFF-52You can continue the discussion on this thread
http://markmail.org/thread/bxgzh5oalbqpf4h7or comment directly on the issue
https://issues.oasis-open.org/browse/XLIFF-52It would be great if we could agree in today's meeting what is the
preferable interpretation.
I would be in favor of the white space interpretation, but would not be
strongly opposed to the strict ( U+0020) interpretation.
Cheers
dF
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, May 15, 2017 at 3:03 PM, Yves Savourel <
ysavourel@enlaso.com> wrote:
> I’m not necessarily thinking U+0020 is the better choice (it would prevent
> any kind of wrapping).
>
>
>
>
>
> Yves Savourel
> Localization Solutions Architect | t: 303.951.4523 <(303)%20951-4523> | f:
> 303.516.1701 <(303)%20516-1701> | ENLASO®
>
>
>
> *From:* Felix Sasaki [mailto:
felix@sasakiatcf.com]
> *Sent:* Sunday, May 14, 2017 2:53 AM
> *To:* Yves Savourel <
ysavourel@enlaso.com>
> *Cc:* public-i18n-its-ig <
public-i18n-its-ig@w3.org>; XLIFF Main List <
>
xliff@lists.oasis-open.org>
> *Subject:* 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 <(303)%20945-3759> | f: 303.516.1701 <(303)%20516-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.
>
>
>
>
>