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

Hi Yves, all,

Yves Savourel wrote:
> Hi Felix, all, 
> 
>>> The only difference is that a selection using a local rule 
>>> stops when it finds an existing local rule, while the global 
>>> rule overrides any global rule already set (and does not 
>>> assume anything about local rules since they will be processed 
>>> after the global rules).
>> or put it differently: Global rules don't know inheritance in 
>> the document tree. We could try to teach them, but I don't know how ...
> 
> Mmmm... Maybe we need to make sure we are all clear on what the global rules behaves first.
> 
> If I have:
> 
> <par class='nt'>some text <b>bold text</b> end of text</par>
> 
> And a rule
> 
> <its:translateRule its:translate='no' its:selector="//*[class='nt']" />
> 
> My understanding is that the content of <b> *does not* get translated.

I think so too.

> 
> If so, it means global rules do know about 'inheritence' (if you define this as the fact a child element gets the ITS information
> set to its parent by the rule).

no, I would define inheritance different, that is: together with
overrides. If you have the document

<par class='nt' its:translate="no"
>some text <b class='t' its:translate="yes">bold <sp class="nt"
its:translate="no">text</sp></b> end of text</par>

and the global rules

<its:translateRule its:translate='no' its:selector="//*[class='nt']" />
<its:translateRule its:translate='yes' its:selector="//*[class='t']" />

its:translate="no" is inherited, until it is overridden by
its:translate="yes". So: no problem with "don't translate <par>,
translate  <b>, don't translate <sp>".
However, as you pointed out earlier, this does not work with global
rules: In the order of the rules above, <par> and <sp> are handled
appropriate, but not <b>. If you reverse the order, the problem is the
other way around.

My impression was that we want to provide users with a means to handle
non-ITS markup *exactly the same way as ITS local markup*. That includes
the inheritance + overriding  behavior described above, and it would not
work with our current realization of document rules.

> 
> 
>>> Having a separate selector and a realize-by value that is 
>>> relative XPath expression is the same as have the selector 
>>> with that relative path added to the absolute root. In 
>>> other words, your notation simply breaks down the absolute 
>>> path. But what purpose breaking the XPath expression serves?
>>> I can't think of any.
>> Sorry, I would rather have only a realize-by value, s.t. like
>> <its:dirRule its:dir="rtl" its:realized-by="//@dir['rtl']"/> 
>> so no need to breaking the XPath expression.
>> ...
>> ...and I would use the attribute "its:realized-by" instead of 
>> "its:selector". With "//@dir['rtl']" in the "its:realized-by" 
>> attribute you describe what markup should be replaced by ITS 
>> markup. With "//*[@dir='rtl']", you don't.
>> You can think of the function of "its-realized-by" as a @match 
>> attribute in XSLT, in a template which realizes the markup 
>> replacement:
> 
> I don't think you can do this because there will be cases where the native markup will not be the same node type as the ITS
> equivalent. For example: you could have a <code> element that contains non-translated data inside a <para> element. Users will want
> to use the 'realize-as' with it because <code> is really equivalent to <code its:translate='no'>. 

Of course 'realize-as' does not replace global rules: for such cases,
you would need

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

And you would have no inheritance + override functionality.

If we don't want to provide users with a means to express local ITS
without using local ITS markup, we don't need "realize-as". The question
then remains how to deal with cases like the cascade of  class="nt" and
class="t" mentioned above.

> So I'm not sure you can point to
> an attribute in all cases. To take other data categories, we may have the reverse: for example, a rubyText-like native construct
> that is an attribute rather than an element like in ITS.

yes, there are many cases which do not work. And I don't like the idea
of just another mechanism myself.

I just have the feeling that the scenario of using class="nt" exactly
like its:translate="no" is very important for adoption of ITS. For
example, the next version of DITA will have an attribute with the ITS
local translatability semantics. Just with global rules, we don't
provide a way to realize the inheritance / overriding part of that
semantics.

Cheers,

Felix