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



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">
>  <segment>
>   <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>
>  </segment>
>  <itsqa:error id="a1" info="Should be USB key" xyz="data"/>
> </unit>
> 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@infodoes.
> 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?
> Cheers,
> -ys

Felix Sasaki
DFKI / W3C Fellow

Received on Saturday, 14 July 2012 18:31:07 UTC