RE: [ACTION-169] Reference Mechanism

Thanks for the additional option Felix.

 

This is nice for the non-dependence on XPath 2.0, but also quite tailored to a use case. We would have to have such pairs of attributes for each piece of information (qa-score, qa-type, etc.) that would make the data category rather complex. Mmm... I need to digest this over the night. Talk to you tomorrow.

 

Cheers,

-yves

 

 

 

From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: Monday, July 23, 2012 8:22 PM
To: Yves Savourel
Cc: public-multilingualweb-lt@w3.org
Subject: Re: [ACTION-169] Reference Mechanism

 

Hi Yves, all,

 

one further solution I could think of would be two "pointer" attributes: one is pointing to the "ref" attribute, the other to the external element:

 

 <its:rules version="2.0">

      <its:qaErrorRule selector="//xlf:mrk[@type='itsqa']"
        errorInfoRefPointer="@ref" errorExternalInfoPointer="//itsqa:error[@id=substring-after($errorInfoRefPointer,'#')]/@info"/>
        xmlns:xlf="urn:oasis:names:tc:entity:xmlns:xml:catalog"/>
    </its:rules>

We when could say that errorExternalInfoPointer MUST contain a variable that is called "errorInfoRefPointer" and is bound by the XPath expression in errorInfoRefPointer.

 

This is also not very clean, but it removes the dependency on XPath 2.0. 

 

Phil, maybe this also helps to make the indirection clearer, let's also discuss this tomorrow.

 

Felix

 

2012/7/15 Yves Savourel <ysavourel@enlaso.com>

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,

-yves

 

From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: Saturday, July 14, 2012 8:31 PM
To: Yves Savourel
Cc: public-multilingualweb-lt@w3.org
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]"
            outputType="new-value-global">
         <output xmlns:xlf="urn:oasis:names:tc:entity:xmlns:xml:catalog"
                 xmlns:itsqa="http://example.com/itsqa">
            <errorInfoRefPointer info="Should be USB key"/>
         </output></node>

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"
        xmlns:xlf="urn:oasis:names:tc:entity:xmlns:xml:catalog"/>
    </its:rules>

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

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

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. 


Best,

 

Felix

 

2012/7/13 Yves Savourel <ysavourel@enlaso.com>

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 (http://www.w3.org/TR/its/#locNote-implementation) or Terminology (http://www.w3.org/TR/its/#terminology-implementation), 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?

Cheers,
-ys







 

-- 
Felix Sasaki

DFKI / W3C Fellow

 





 

-- 
Felix Sasaki

DFKI / W3C Fellow