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

Hi Yves, all,

Yves Savourel wrote:
> Hi Felix, all,
> 
>> at http://www.w3.org/TR/its/#selection-defaults-etc , we define 
>> "default" selections. I think for translatability this means if 
>> the have <p its:translate="..">...</p> the value of the 
>> translate attribute is related to "Textual content of element, 
>> including content of child elements, but excluding attributes", 
>> no matter what the value is.
> 
> OK I see now.
> 
> 
>> Now, a global rule like <its:dirRule select="//p" its:dir="rtl"/> 
>> selects only the <p> elements, not their attributes. The same 
>> is true for a global rule like <its:translateRule select="//p" 
>> its:translate="..."/> this rule does not say "attributes are not 
>> translatable": it just does not talk about attributes.
> 
> Actually I could disagree here: as you say we have nothing that specify what the selection is for global rules. I assumed it was the
> same as for local rules. There is nothing that says it, but there is nothing that says otherwise either.
> 
> It seems logical that the selection of a global rule and a local one be the same.

O.k.

> 
> I would propose to change in 5.1 the column header "default selection in instance document" to "default selection" (or something
> equivalent, stating clearly that it is for the data category regardless whether it's a global or local rule.
> 
> 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 ...

> 
> As for the 'real mappings' they are basically like a global rule that act like a local one.

yes.

> 
> Which corresponds to your illustration that the mapping is like a replacement of the native markup by the ITS local markup.
> 
> 
>> So here is my proposal:
>>
>> 3) to be able to say "existing local markup has the same 
>> meaning like ITS local markup" , we have:
>> <its:dirRule its:selector="//*" its:dir="ltr"
>> its:realized-by="@dir['ltr']"/>
>> which means "the data category 'directionality' with the 
>> value 'ltr' is realized by @dir['ltr']"
>> <its:dirRule its:selector="//*" its:dir="rtl"
>> its:realized-by="@dir['rtl']"/>
>> which means "the data category 'directionality' with the 
>> value 'rtl' is realized by @dir['rtl']"
> 
> 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.

> 
> This means, mapping could (and I think should) have the exact same notation as a normal rule, except that it is a map. So we would
> have something like:
> 
> <its:dirMap its:dir="rtl" its:selector="//*[@dir='rtl']" />

no, I think I would write
<its:dirMap its:dir="rtl" its:realized-by="//@dir['rtl']" />
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:

<xsl:template match="//@dir['rtl']">
<xsl:attribute name="its:dir">rtl</xsl:attribute>
</xsl:template>

The difference in processing of its:select versus its:realized-by would be:
- its:realized-by matches the nodes which have to be replaced by the
data category attribute. *After* that replacement process, they can be
handled as normal local ITS markup.
- its:select matches the nodes and applies ITS information to them.


> 
> That would also means the order in which maps are in the documentRules does not matter.

yes.

> 
> The most difficult part would be to explain to the users what is the difference and when to use one versus the other...

How about this "rule of thumb":
- use "its:selector + data category attribute" if there is no ITS
information in the instance document at all
- use "its:realized-as + data category attribute" if there is
information with the exact meaning of ITS, but different markup (e.g.
"trans" attribute instead of "translate".


Do we need "its:realized-as"? I have the feeling we do, if we want to
give people the ability to use their own markup with exact the same
meaning as ITS markup. This includes the same inheritance behavior, and
the same position in precedence rules, i.e. "1":

   1. Implicit local selection in instance documents (data category
attributes on a specific element, which might origin in a transformation
via "realized-as" rules)
   2. Local selections in instance documents (using a documentRules element)
   3. Global selections in an external file (using a documentRules element)
   4. Global selections in a schema, expressed with a documentRules element
   5. Selections expressed with schemaRule (See also the note in Section
5.1.2: Global, Rule-based Selection)
   6. Selections via defaults for data categories, see Section 6.1:
Position and Default Selections of Data Categories

However, if we don't want to include inheritance behavior and precedence
order, then we don't need this "just another mechanism" ...

Sebastian, what do you think, from the perspective of your XSLT
implementation?

- Felix