W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2006

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

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 22 Mar 2006 14:22:43 +0900
Message-ID: <4420DF23.3090903@w3.org>
To: Felix Sasaki <fsasaki@w3.org>
Cc: Yves Savourel <ysavourel@translate.com>, public-i18n-its@w3.org
After writing my mail, I realized that my proposal is what Yves called
"mapping" at
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0352.html :

[[I would assume that such mapping means the element/attribute in the
host format has the exact same semantics as the ITS information.
It other words we should be able (conceptually) to replace the host
markup by the its corresponding markup.]]

My proposal says: don't replace the host markup conceptually, but in
reality.

Another point specific to my proposal:

<its:dirRule its:selector="//*" its:dir="ltr"
its:realized-by="@dir['ltr']"/>

is used *only* for saying "existing markup has the *exact* same meaning
as ITS markup." That is, we don't say "realized-by" for a data category
in general, but for the data category with a specific value, e.g. "ltr"
for directionality. In other words: this makes only sense for discrete
values.

- Felix

Felix Sasaki wrote:
> Hi Yves, all
> 
> I have thought about this problem and the translatability problem for a
> long time, and I think this is a case where we really want to separate
> purposes of global rules.
> 
> I think we should reserve the usage of "its:selector + data category
> attributes "only for the purpose "selecting and adding information".
> What we try with s.t. like its:selector="//*[@dir='ltr'], is rather
> saying "@dir has the meaning of local its:dir", and causes all the
> problems you found out.
> 
> In addition to the problems you mentioned in your mails about
> directionality and translatability, there is another one: the global
> rules don't take the default selections in the instance into account.
> 
> 
> So here is my proposal:
> 
> 1) <its:dirRule its:selector="//*" its:dir="ltr"/> is used for selecting
> and adding information globally (as usual).
> 2) <its:locInfoRule its:selector="//*" its:locInfoContent="@loc-note"/>
> is used for pushing information globally (as already accepted, we only
> have to decide about the name of the attribute: "xxxContent", "xxxPush",
> ...).
> 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']"
> 
> 
> Then processing ITS information (global and local), 3) would be used to
> create the data category attributes in the document. E.g, your document
> then would look like
> 
> <myDoc xmlns:its="http://www.w3.org/2005/11/its">
>  <head>...
>  </head>
>  <body>
>   <par its:dir='ltr'>LTR text <span its:dir='rtl'>RTL text</span> LTR
> text.</par>
>   <par its:dir='rtl'>RTL text <span its:dir='ltr'>LTR text</span> RTL
> text.</par>
>  </body>
> </myDoc>
> 
> it depends on your implementation whether you really create a new
> document, or just make two passes through one document: one to create
> the local ITS markup (i.e. to process 3), and one to process local ITS
> markup (no matter if it was already in the instance or was created via
> 3) before).
> 
> Solution 3) solves all problems we had before, since the new attributes
> are just treated as "native" ITS attributes.
> 
> What do you think?
> 
> Cheers,
> 
> Felix
> 
> 
> Yves Savourel wrote:
>> Hi all,
>>
>> Looking at directionality it seems we have the same issue as the one I described in
>> http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0368.html.
>>
>> For example:
>>
>> <myDoc xmlns:its="http://www.w3.org/2005/11/its">
>>  <head>
>>   <its:documentRules>
>>    <its:dirRule its:selector="//*[@dir='ltr']" its:dir="ltr"/>
>>    <its:dirRule its:selector="//*[@dir='rtl']" its:dir="rtl"/>
>>   </its:documentRules>
>>  </head>
>>  <body>
>>   <par dir='ltr'>LTR text <span dir='rtl'>RTL text</span> LTR text.</par>
>>   <par dir='rtl'>RTL text <span dir='ltr'>LTR text</span> RTL text.</par>
>>  </body>
>> </myDoc>
>>
>> Here no matter how you arrange the rules, one of the <span> contents will end up flagged as the same direction specified in the dir
>> attribute of its <par> parent, which is obviously wrong.
>>
>> Here again, the problem is that the global rules for dir (according the defintion here:
>> http://www.w3.org/International/its/itstagset/itstagset.html#selection-defaults-etc) has the direction inherited by its children,
>> and we have no way to know if one of the children corresponds to another direction specified earlier in the rules.
>>
>> I'm guessing that here again, the solution would be an additional attribute that would flag a rule has being not overwritable by the
>> next rules.
>>
>> Something like:
>>
>> <myDoc xmlns:its="http://www.w3.org/2005/11/its">
>>  <head>
>>   <its:documentRules>
>>    <its:dirRule its:selector="//*[@dir='ltr']" its:dir="ltr" its:overwritable="no" />
>>    <its:dirRule its:selector="//*[@dir='rtl']" its:dir="rtl" its:overwritable="no" />
>>   </its:documentRules>
>>  </head>
>>
>> ... Then cases like this would work:
>>
>>  <body>
>>   <par dir='ltr'>LTR text <span dir='rtl'>RTL text</span> LTR text.</par>
>>   <par dir='rtl'>RTL text <span dir='ltr'>LTR text</span> RTL text.</par>
>>   <par dir='rtl'>RTL text <b>bold RTL text</b> RTL text.</par> </body>
>> </myDoc>
>>
>> It's easy to implement in a decorated tree, but I'm not sure how that would work for XSLT or Xquery implementation.
>>
>> I think it's important that we solve this very soon, because currently it makes any markup similar to ITS local markup not very
>> useable throught ITS.
>>
>> Cheers,
>> -yves
>>
>>
>>
>>
>>
> 
> 



Received on Wednesday, 22 March 2006 05:22:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:06 UTC