Re: [ACTION-153] related to [ISSUE-15] targetPointer

Hi Yves,

I would have no objections against this, and would favor the relative XPath
expression proposal. just one question:

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

> Hi all,
>
> I have the action item to summarize the status of the targetPointer
> requirements
> This related to ISSUE-15.
>
> The current requirement (
> http://www.w3.org/International/multilingualweb/lt/wiki/Requirements#targetPointer)
> outlines several use cases.
>
> I think the current status is:
>
> - There is 3 intended implementations.
>


Could you talk to the people who showed implementation interest that this
is still the case? In some cases I had the impression that the commitment
was not always 100% clear.

Thanks,

Felix



>
> - It seems all questions about the reasons to have such feature have been
> answered in Dublin.
>
> - The exact scope and model of the data category needs to be finalized.
>
> So here is more thoughts to try to make this progress:
>
> First, like for idValue, I believe now that this should be its own data
> category rather than an addition to the Translate data category: the
> feature should be available without using Translate.
>
> As far as how to indicate the target, I think there is a distinction of
> what can be achieved depending on the way we set this up:
>
> Shaun was illustrating his thoughts with:
>
>  selector="//license[@xml:lang='en']" repeatable="yes"
>
> To describe a case like this:
>
> <application>
>  <license xml:lang="en">
>   <p>This is the license.</p>
>   <p>It has multiple paragraphs.</p>
>  </license>
>  <license xml:lang="de">
>   <p>Dies ist die Lizenz.</p>
>   <p>Es verfügt über mehrere Absätze.</p>
>  </license>
> </application>
>
> Such notation however:
>
>  a) It would not work for cases where the target(s) are in non-sibling
> nodes.
>
>  b) It would work only if the document uses xml:lang to distinguish the
> different language blocks (as it is the only implicit difference one can
> make in the example).
>
> <application>
>  <src>
>   <license>
>    <p>This is the license.</p>
>    <p>It has multiple paragraphs.</p>
>   </license>
>  </src>
>  <targets>
>   <target langCode='1'>
>    <license>
>     <p>Dies ist die Lizenz.</p>
>     <p>Es verfügt über mehrere Absätze.</p>
>    </license>
>   </target>
>  </targets>
> </application>
>
> Or, more simply, for bilingual cases where the content is a single element:
>
> <msgs>
>  <m id='1'>
>   <src>Text of the message</src>
>   <trg>Texte du message</trg>
>  </m>
> </msgs>
>
> So, I think an XPath relative expression would be more flexible because it
> would allow both use cases:
>
> <its:targetPointerRule "//license[@xml:lang=$SourceLang]"
> targetPointer="../license[@xml:lang=$Target]"/>
>
> <its:targetPointerRule "//src"
> targetPointer="../targets/target[@langCode=$TargetCode]"/>
>
> However, this method has also a possible drawback: like with Shaun's
> example, with more complex expressions creating the target node if it does
> not exist, may be complicated.
>
> I wonder if then the data category scope could be limited to work, at
> least, with existing nodes?
>
> Anyway, I hope you will have some additional ideas.
> >From the experience we had with ITS 1.0 I know this is a feature that
> would be used.
>
> -yves
>
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow