- From: Yves Savourel <ysavourel@enlaso.com>
- Date: Fri, 13 Jul 2012 09:29:43 +0200
- To: <public-multilingualweb-lt@w3.org>
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
Received on Friday, 13 July 2012 07:30:12 UTC