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@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****
>
> ** **
>



-- 
Felix Sasaki
DFKI / W3C Fellow