At 15:41 2003 02 19 +0100, Yann Dirson wrote:
>On Wed, Feb 19, 2003 at 08:19:20AM -0600, Paul Grosso wrote:
>> At 21:38 2003 02 18 -0600, Paul Grosso wrote:
>> 
>> >My very untutored understanding is that there are two key branches here:
>> >
>> >1.  There is markup delimiting the language change--whether it is
>> >    specifically markup to "change language" or it is other markup
>> >    such as "foobar-number" whose content is known to require a
>> >    direction change (e.g., numbers in Hebrew are written left-to-right).
>> >
>> >    In this case, there is nothing more we need in the DTD. 
>> 
>> Actually, I mispoke here.  What we should probably do is
>> add a "direction" attribute to the <phrase> element in
>> a fashion somewhat parallel to what HTML allows [1].  I
>> think <phrase> can be used for this purpose, but I suppose
>> we could add a "bidi" element (along the lines of HTML's
>> bdo element [2] or XSL-FO's bidi-override element [3]) if 
>> we don't wish to use <phrase>.  Note that this element needs 
>> to be able to nest within itself.
>
>Is that necessary ?  Isn't possible to infer the writing direction
>from the value of the "lang" attribute, without adding anything new ?

I don't think so.  Note at [1] that:

  User agents must not use the lang attribute to determine text directionality.

>For special cases like the Hebrew numbers, what about going more
>semantic and provide a "number" element ?

I don't believe we can/should make "semantic" elements for all sorts
of things like this, though certainly someone could put role="number"
on a phrase element if they so desired and have the stylesheet key in
on that to change the direction.

The fact is that both HTML and XSL-FO have a "bidi" element and a
"direction" attribute/property.  We could check with the W3C I18N folks
to see if they wish to provide a suggestion, but it looks to me like
our target output formats both support such elements and attributes,
so it probably makes sense for our DTD to do likewise.

paul

Reply via email to