W3C home > Mailing lists > Public > public-iri@w3.org > March 2010

RE: BIDI IRI Display (was spoofing and IRIs)

From: Larry Masinter <LMM@acm.org>
Date: Wed, 3 Mar 2010 18:00:32 -0800
To: "'Shawn Steele'" <Shawn.Steele@microsoft.com>, "'Slim Amamou'" <slim@alixsys.com>
Cc: <public-iri@w3.org>, "'Peter Constable'" <petercon@microsoft.com>, <unicode@unicode.org>
Message-ID: <001901cabb3e$7b2a59e0$717f0da0$@org>
If the same Unicode string is used for an IRI in running text and for
an IRI in a context where its use as a "ordered list", then it would
seem like 

* the presentation of the IRI in different contexts is the same

is more important than

* the presentation of the IRI in known IRI contexts is optimal

Do you agree? I don't see how you can have both.


-----Original Message-----
From: Shawn Steele [mailto:Shawn.Steele@microsoft.com] 
Sent: Wednesday, March 03, 2010 9:13 AM
To: Slim Amamou; Larry Masinter
Cc: public-iri@w3.org; Peter Constable; (unicode@unicode.org)
Subject: RE: BIDI IRI Display (was spoofing and IRIs)

> An IRI is a sequence of Unicode characters. Is there not
> already a well-defined way of converting a sequence of
> Unicode characters to a visual display?

The problem (from my perspective at least) is that the Unicode BIDI
rules are somewhat "generic".  Unicode expects things like / and . to
be used in a context of same-script stuff, like a date, time or
number.  IRIs use them as delimiters for a list of elements (labels in
the domain name or folders in the path), in a hierarchical form.  The
Unicode BIDI algorithm doesn't recognize that there's an underlying
hierarchy, so it can end up "swapping" pieces in that hierarchy in
some cases.

I'm not sure UTR#36 is the proper place to clarify display of such
ordered lists.  Proper BIDI rendering of IRIs isn't just a security,
but also a usability, problem.  It does seem like perhaps this concept
should be mentioned in Unicode somewhere.  (IRIs aren't the only place
that similar ordered lists happen).

Received on Thursday, 4 March 2010 02:01:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:41 UTC