RE: IRI-Everywhere

> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On 
> Behalf Of Jeremy Carroll
> Sent: Tuesday, November 12, 2002 8:21 PM
> To: www-tag@w3.org
> Subject: IRI-Everywhere
> ...

Jeremy,

thanks for the analysis.

I'd like to add a few facts that seem to get overlooked again and again :-)

1) Allowing the space character in IRIs makes it impossible to use the space character as delimiter between IRIs. Specs that as of now use white-space separated lists of URIs (such as XML Schema for namespaceLocation) *will* break if an IRI contains a space character.

2) IRIs are not URIs (well, many of them). "Silently" replacing URI (refs) by IRI (refs) in spec revisions (such as XML namespaces) potentially breaks applications that assume URI-ness (such as that only ASCII characters are used).

3) QName vs URI: if XML namespaces allow IRI refs as namespace names, the issue of mapping QNames to URIs will get even messier as it *already* is.

For the record: I'm in favor of IRIs

- if they stay focused on the issue of I18N -- allowing whitespace in the identifier does not really fit into this requirement (IMHO),

- if it's always clear whether you're looking at a IRI or a URI (when specs "upgrade" from URI to IRI, this may require out-of-band information),

- if they require full normalization

Proposal/Question:

- would it make sense to deprecate URIs that can not be transformed to IRIs (that is, those URIs that do contain %-escapes that do not map to UTF-8 representations of fully normalized Unicode strings)? 


Julian


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 13 November 2002 16:55:39 UTC