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

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.

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).


>> 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'>. 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.

Cheers,
-yves

Received on Thursday, 23 March 2006 16:55:19 UTC