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

Hi Yves, all,

After thinking about my "just another mechanism" proposal again, I was
wondering how it could be simpler and directed to a different target
than "normal" global rules.

The only usage scenario for this "mapping" which I see is, if people
want to use ITS "like" markup, but in their own namespace, and possibly
with different names.

So how about just having "mapping" just on this level, i.e. of names:

<its:documentRules>
<its:mapMarkup sourceAttribute="its:translate" targetAttribute="trans"/>
<its:mapMarkup sourceElement="its:ruby" targetElement="odf:ruby"/>
...
<its:translateRule .../>
</its:documentRules>

the <mapMarkup> element then would have a clearly separated purpose then
the global rules: mapping of names of elements and attributes, to allow
their usage with the identical semantics as local ITS markup.

What do you think?

Cheers,

Felix

Felix Sasaki wrote:
> 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
>