W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > July 2012

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

From: Phil Ritchie <philr@vistatec.ie>
Date: Mon, 9 Jul 2012 16:59:09 +0100
To: Yves Savourel <ysavourel@enlaso.com>
Cc: <public-multilingualweb-lt@w3.org>
Message-ID: <OF8DA4C582.07B9350A-ON80257A36.00577543-80257A36.0057D07A@vistatec.ie>
Yves

What do relative XPath expressions give you that absolute ones do not? Is 
relative purely to simplify the expressions themselves? Does XPath 
normally prohibit relative expressions?

<quote>
<its:targetPointerRule "//license[@xml:lang=$SourceLang]" 
targetPointer="../license[@xml:lang=$Target]"/>

<its:targetPointerRule "//src" 
targetPointer="../targets/target[@langCode=$TargetCode]"/>
</quote>

Do "//license[@xml:lang=$SourceLang]" and "//src" not need an attribute 
name?

Phil.





From:   Yves Savourel <ysavourel@enlaso.com>
To:     <public-multilingualweb-lt@w3.org>, 
Date:   09/07/2012 16:21
Subject:        [ACTION-153] related to [ISSUE-15] targetPointer



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.

- 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 




************************************************************
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
************************************************************
Received on Monday, 9 July 2012 15:59:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:47 UTC