W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2006

Re: Directionality Scope/inheritance issue (same as translatability)

From: Felix Sasaki <fsasaki@w3.org>
Date: Mon, 27 Mar 2006 13:18:28 +0900
Message-ID: <44276794.3030202@w3.org>
To: Yves Savourel <yves@opentag.com>
Cc: 'Sebastian Rahtz' <Sebastian.Rahtz@oucs.ox.ac.uk>, public-i18n-its@w3.org
Yves Savourel wrote:
> Hi Sebastian,
> 
>> Now (sorry, I am being slow here!), where do I worry 
>> about ambiguity? the results are correct, yes?
> 
> In the second paragraph:
> 
> <p trans="false">some text <code>code <textInCode>text in code</textInCode>code</code>.</p>
> 
> The content of <textInCode> should be not translatable because trans='true' in the <p> element.
> 
> That is assuming trans='true|false' has the same behaviour as its:translate, (like a dita:translate).
> 
> In other words, we have cases of native markup like <code> and <textinCode> (case 1) that are not directly related to
> translatability but need to be specified in our rules (simply because the nature of their content make them translatable or not),
> and we have cases like trans='true|false' (case 2) that should mimic its:translate. The rules of case 2 should overwrite rules of
> case 1, but sometimes rules of case 1 should not overwrite other rules of case 1 (for example when <code> can be within <textInCode>
> and <textInCode> can be within ,code>) because re-ordering the rules can't work for them. 
> 
> ...I think.

Hi Yves, Sebastian, all,

Below I tried to separate these two cases.

My understanding is that local markup like its:translate "selects" the
node to which ITS attributes are attached to. A second part of the
interpretation is then how inheritance is handled . In the case of
its:translate, all elements, but no attributes. In the case of its:dir,
both elements and attributes.

Hence,
<p its:translate=".." its:dir="..>...</p> has its:translate and its:dir
*selecting* the same <p> node, but with different inheritance behavior.

Now, as for global rules, they also select nodes, and have as a second
part of their interpretation the application of inheritance, identical
with ITS markup local usage.

Now, if we follow that route, "conflicts" between global rules do occur at

- directly selected nodes, this is your case 2)

 and *not* at

-) the inheritance starting from them, this is your case 1)

My impression was that only for 2), we need the precedence resolution,
currently handled via the order between global rules. If you look at the
current draft, there are only examples of 2) like

<its:translateRule its:select="//p" its:translate="yes/>
<its:translateRule its:select="//p[1]" its:translate="no"/>

but no examples of 1) like

<its:translateRule its:select="//p" its:translate="yes/>
<its:translateRule its:select="//code" its:translate="no/>

assuming that <code> is in <p>.

I think going for 1) is a dangerous route, since it breaks the
parallelism between global and local ITS markup. If we don't have this
parallelism of global and local ITS markup, people don't have a way to
use their own translatability markup like its:translate.

Btw., I think 2) would be enough to cater the case which you mentioned
at some point during this discussion, at
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0374.html :

<myDoc xmlns:its="http://www.w3.org/2005/11/its">
 <head>
  <its:documentRules>
   <its:dirRule its:selector="//*[@dir='ltr']" its:dir="ltr"/>
   <its:dirRule its:selector="//*[@dir='rtl']" its:dir="rtl"/>
  </its:documentRules>
 </head>
 <body>
  <par dir='ltr'>LTR text <span dir='rtl'>RTL text</span> LTR text.</par>
  <par dir='rtl'>RTL text <span dir='ltr'>LTR text</span> RTL text.</par>
 </body>
</myDoc>


With 2), there will be no precedence problem anymore, since the two
"dir" rules don't select the same nodes *directly*. The inheritance
precedence problem will be solved as with ITS local markup. Hence, you
don't need the attribute its:overwritable="no" which you proposed at
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0374.html .

I tried to solve the problem mentioned at 0374.html ; the problem 1) you
mentioned above seems to me a different one, which came up somehow
during the discussion.

In a previous mail, you wrote:

[[The @trans='false|true' is clearly an ITS-equivalent markup. But
things like <code> and <textInCode>, while it has implication from
> the translatability viewpoint, is not equivalent to <its:span
its:translate>: For example they needs to be overwritten if there is a
> @trans='false|true' in their parent. In the other hand things like
<span trans="false"> should not be overwritten. We need to cater
> to both cases.]]

I think there is a way to achieve what you want, just by going for 2)
and by saying:

<its:documentRules xmlns:its="http://www.w3.org/2005/11/its">
1 <its:translateRule its:translate="yes" its:selector="//textInCode"/>
2 <its:translateRule its:translate="no" its:selector="//code"/>
3 <its:translateRule its:translate="yes"
its:selector="//*[@trans='true']/descendant-or-self::*"/>
4 <its:translateRule its:translate="no"
its:selector="//*[@trans='false']/descendant-or-self::*"/>
</its:documentRules>

Since "//*[@trans='false']/descendant-or-self::*" and
"//*[@trans='true']/descendant-or-self::*" select *directly, without
inheritance*, all nodes with @trans attributes *and their children*, the
translate rules 3 and 4 have a precedence conflict with 1 and 2 for
<textInCode> and <code> elements within <... @trans="..."> elements. And
of course 3 and 4 win.

If you want to have exceptions from the direct selection in 3 and 4,
e.g. for a <someElement> element, you would write

<its:translateRule its:translate="no"
its:selector="//*[@trans='false']/descendant-or-self::*[not(name()='someElement')]"/>

Just a last comment on your proposal for the priority attribute: I think
it causes questions like

- What priority is meant by this attribute? Priority in the sense of 2)
(between global rules selecting directly the same nodes) or 1) (priority
including inherited nodes)?
- IMO 2) is a mandatory kind of priority. Only with 2), e.g. the DITA
folks can use ITS markup in their own namespace, and others can use
<translateRule> to make the semantic identity clear. If you still want
1), the question then arises how you specify at a global rule what kind
of priority you mean?
- How would cases like the following be handled with @its:priority:

<its:translateRule its:select="//*" its:tranlate="no" its:priority="1"/>
<its:translateRule its:select="//p" its:translate="yes" its:priority="1"/>

Since there are the same priority value, an implementation does not know
which rule should win for <p> elements. This problem does not occur with
the current implementation of priority, due to the total ordering of
rule elements.

I'm afraid my mail will still not create consensus. If Sebastian does
not solve the problem ;) , how about continuing the discussion on this
at the April f2f? Sebastian mentioned the need for test cases, input
(with and without your proposed "precedence" attributes) and output,
which we could use then. Also, in the next draft, we could put an
editor's note asking whether there are many people who want the
functionality of 1).

Cheers,

Felix


> 
> Cheers,
> -yves
> 
> 
> 
> 



Received on Monday, 27 March 2006 04:18:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:06 UTC