Re: Bidi issues

 > Well, the question is which order is the right one.
 > In an LTR context, BARA.BEW.com is obviously better.

It wasn't obviously better (to me).  It bothers me that it's
'middle-endian', with the least-significant component in the middle.

I was naively assuming that 

	BEW.BARA.com and
	com.BARA.BEW

were the only sensible ways of writing the domain.

I hadn't grasped the idea that most users of RTL languages will be
sufficiently used to LTR-in-RTL embeddings that they will find it
natural to read this construct in logical order.  (Even though this is
actually an RTL-in-LTR embedding, the principle is familliar enough
that users are happy with it, presumably?)

 > To some extent, the more LTR pieces you have, the better
 > it looks in LTR context, and the more RTL pieces you have,
 > the better it will look in RTL context. But judgement is
 > difficult, and creating an algorithm that counts pieces,...
 > would be too complex. So we took LTR as a base, rather
 > than RTL.

Which makes sense, particularly since all (present day) computer users
will be used to the fact that current identifiers are LTR.

 > If you know that periods are special, and read each label
 > independently, then you are right. But the feedback we got
 > is that people not familiar with domain names or URIs
 > won't necessarily know that. For people who don't know
 > that, they probably always read 'foo.com' LTR, and
 > 'BARA.BEW' RTL.

Right.  It's a matter of assumptions, and mine were biased by looking
at the structure of the domain, rather than at the assumptions that a
user of an RTL lanuage would make.

 > There is no place here for "user's preferred writing direction".
 > If we put something on the side of a bus, or on a name card,
 > the user's preferred writing direction is lost.

You're right.  I misunderstood the original point about WEB.ARAB.COM
rendering as MOC.BARA.BEW rather than BEW.BARA.MOC (and thought this
was an option depending on bidi embedding level or something).

 > I'm not sure it was discussed on the IDN list. The IDN list mainly
 > cared about getting a predictable display for single labels.
 > It was the solution originally proposed for IRIs.

I'm sure someone proposed that labels should always be presented least
significant on the left to most significant on the right, and outlined
the algorithm for doing so.  I haven't followed any of the IRI
discussion (except where it was referenced on the IDN list) so I don't
think it's that I'm thinking of.

 > >I'm not sure the same issues really occur with local parts, though,
 > >since separators only have local significance.  There isn't really any
 > >global 'right' order in which to display the segments of a local part,
 > >since the very notion of segments is internal to IMAA.
 > 
 > That's a statement that makes sense to somebody understanding the
 > specs in detail. What we have to care about is the end users.

Possibly, but there is no spec for the structure of a local part.  So
saying 'just render it according to the bidi algorithm' (as you have
decided is also correct for IRIs -- which *are* structured) seems
natural.

What restrictions -- if any -- should be made on the content of a
local part is a somewhat separate issue (though it's what caused me to
start this thread).

	-roy

Received on Thursday, 7 August 2003 16:35:24 UTC