RE: [ACTION-169] Reference Mechanism

Hi Felix, all


Nice expression. It’s good to see that it’s somewhat doable.


But obviously the dependency to XPath 2.0 is damping my enthusiasm. A minor other question is whether such expression qualifies as ‘relative to the selected node’? But, even if not, I suppose we could change the second part of the expression to get the itsqa:error element differently.


If there is no XPath 1.0 solution, would there be another way to define itsqa:error so it can be used more easily with a relative XPath 1.0 expression? 


In any case, I think your solution certainly removes the road block I was afraid of. I just wish the detour would be easier.


Enjoy your vacations,



From: Felix Sasaki [] 
Sent: Saturday, July 14, 2012 8:31 PM
To: Yves Savourel
Subject: Re: [ACTION-169] Reference Mechanism


Hi Yves,


I implemented the its:qaErrorRule element, and was able to resolve the reference to

info="Should be USB key"

My "artificial" output looks like this:

<node path="/doc/body[1]/xlf:unit[1]/xlf:segment[1]/xlf:target[1]/xlf:mrk[1]"
         <output xmlns:xlf="urn:oasis:names:tc:entity:xmlns:xml:catalog"
            <errorInfoRefPointer info="Should be USB key"/>

That is, I associate 

info="Should be USB key"

with the "mrk" element, which I think is what you want.


The rules file for doing this looks like this:

 <its:rules version="2.0">
      <its:qaErrorRule selector="//xlf:mrk[@type='itsqa']"
        errorInfoRefPointer="for $ref in @ref return //itsqa:error[@id=substring-after($ref,'#')]/@info"

You see that solving the problem has a price: I am using XPath 2.0. This gives me the ability to write the following relative path expression:


for $ref in @ref return //itsqa:error[@id=substring-after($ref,'#')]/@info


This means that I am binding the "ref" attribute to a variable. with the part


I am then getting the "info" attribute that I need.


So if we go this route implementations that want to do the level of indirection need to use XPath 2.0. There might be a solution with XPath 1.0, maybe Jirka has an idea? Otherwise, I would prefer to use XPath 2.0 instead of introducing a new mechanism in global rules for resolving the reference. 





2012/7/13 Yves Savourel <>

Hi everyone,

While discussing the qa-error data category we ran into a use case where using inline attributes is not practical and where, instead, some reference mechanism is needed. This issue may not be specific to the qa-error data category.

The current proposal for qa-error calls for using one or more local attributes that can be applied directly to the content of the element where they are. For example:

<p>Insert the <span its-error="yes" its-error-info="Should be USB key" its-error-xyz="data">Pen Drive</span> in the USB port</p>

A example of a format where this is not practical is XLIFF 2.0:

In such file the element used to annotate the content (<mrk>) does not allow non-XLIFF attributes. Instead it offers two options:

a) to use user-defined types along with a single string value:

<target>Insert the <mrk id="m1" type="mytype" value="myvalue">Pen Drive</mrk> in the USB port</target>

Or b) to use a user-defined type along with a pointer to an element residing in the unit where the content is located. That element can be user-defined. For example:

<unit id="1">
  <source>Insérez la clé USB dans le port USB.</source>
  <target>Insert the <mrk id="m1" type="itsqa" ref="#a1">Pen Drive</mrk> in the USB port</target>
 <itsqa:error id="a1" info="Should be USB key" xyz="data"/>

This example has the ITS qa-error data category implemented. But a tool that is just ITS-aware cannot find the corresponding info for it.

The solution is similar to the data categories such as Localization Note ( or Terminology (, where we define global rules that map the data category features to the non-ITS markup.

The possible extra catch here is that, as far as I can tell--and I really hope a URI expert will contradict me here--none of the pointing mechanisms we have in ITS 1.0 can handle the reference used in the XLIFF case.

For example, with something like:

<its:qaErrorRule selector="//xlf:mrk[@type='itsqa']" errorInfoRefPointer="@ref"/>

errorinforefPointer would contains a relative XPath expression pointing to a node that holds the URI referring to the error information. But itsqa:error does not contain directly that information, itsqa:error@info does.

So, the question is: is there a pointing mechanism that we could use to map the different data of qa-error to either attributes or elements that are grouped under a single element?



Felix Sasaki

DFKI / W3C Fellow


Received on Sunday, 15 July 2012 06:23:13 UTC