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

Hi Felix, all,

> How about differencing two processing steps 
> instead:
> - step 1): global rules are applied to instance 
> documents. result: its markup is integrated into 
> the document (in memory, or written to a file; 
> that depends on your implementation). the markup 
> is "flagged" as being global.
> - step 2): the output is handled with inheritance 
> and default rules for local markup.

Isn't doing this the same as reversing our rules order: Now the first rule wins?

The problem is that now we have no way to deal with non-ITS like markup.
If you take this example:

<myDoc>
 <head>
  <its:documentRules xmlns:its="http://www.w3.org/2005/11/its">
   <its:translateRule its:translate="yes" its:selector="//textInCode"/>
   <its:translateRule its:translate="no" its:selector="//code"/>
   <its:translateRule its:translate="yes" its:selector="//*[@trans='true']"/>
   <its:translateRule its:translate="no" its:selector="//*[@trans='false']"/>
  </its:documentRules>
 </head>
 <body>
  <p><code>code <textInCode>text in code <code>code in text</code></textInCode></code></p>
  <p trans="false">some text <code>code <textInCode>text in code</textInCode>code</code>.</p>
  <p><code trans="true">code <textInCode trans="false">text in code <code trans="true">code in text</code></textInCode></code></p>
 </body>
</myDoc>

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.

If you process this file with the rule we have today (last rule wins), it does not work in several cases and no amount to tinkering
with the rules order will solve this.

I'm not sure yet how it will work the way Felix proposes. But if it's the same as a 'first rule wins' like I think, then it probably
won't work well for the <code> and <textInCode> cases when they are nested.

But what Felix proposes is closer to a solution it seems. Except I would think we need to control the way the
inheritance/overwriting is done.

I've been discussing the problem with Shigemichi Yazawa (he is at ENLASO too and some of you know him), and he noted that maybe we
could have a priority of some sort associated with the rules. I think this would be better than the 'allowOverwrite' flag I was
think about, and it reminds me of what Sebastian was doing with his XSLT implementation to get the right precedence order.

The idea would be that rules of priority 3 would overwrite the ones of priority 2 and 1, the ones of priority 2 would overwrite the
1s, etc. And when two rules have the same priority they would not overwrite each other.

This would allow to build 'groups of rules' and controlling how they interact for inheritance.
Something like:

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

Elegance may lead use to think about real group element too...

I haven't really try this yet or though it throught (like what: is the impact in the order of the rules), but I have the feeling
this (or something related to this) could be a way to solve the problem.

Some food for your week-end's thoughts :)

Cheers,
-yves

Received on Friday, 24 March 2006 23:28:05 UTC