Re: [ACTION-169] Reference Mechanism

I have successfully used Yves' (b) mechanism with XSLT 2.0 and XLIFF 1.2 
to transform proprietary segment related elements in XLIFF to HTML 5 with 
data. In the examples below I'm struggling to understand all of the 
indirection.

Phil.





From:   Felix Sasaki <fsasaki@w3.org>
To:     Yves Savourel <ysavourel@enlaso.com>, 
Cc:     public-multilingualweb-lt@w3.org
Date:   14/07/2012 19:32
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


************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail.

www.vistatec.com
************************************************************