W3C home > Mailing lists > Public > xml-names-editor@w3.org > February 2003

Re: comparing IRI references, in http://www.w3.org/TR/xml-names11/#IRIComparison

From: Martin Duerst <duerst@w3.org>
Date: Wed, 05 Feb 2003 12:40:48 -0500
Message-Id: <>
To: "Larry Masinter" <LMM@acm.org>, <chris@w3.org>, "Tim Bray" <tbray@textuality.com>
Cc: <xml-names-editor@w3.org>, Michel Suignard <michelsu@microsoft.com>

Hello Larry,

Many thanks for your mail. When I looked at
over the last days, I was thinking exactly in the
same direction.

At 07:58 03/02/05 -0800, Larry Masinter wrote:
>I think there's quite a bit of discomfort with
>section 2.3 because of its implication for IRI
>   http://www.example.org/ros&eacute;

[I have substituted &eacute; for the actual character
because it doesn't survive my Japanese mailer :-(]

>   http://www.example.org/ros%c3%a9
>   http://www.example.org/ros%c3%A9
>   http://www.example.org/ros%C3%a9
>   http://www.example.org/ros%C3%A9
>I think the problem is that the Candidate Recommendation
>makes no recommendation about the possible simultaneous
>use of all of these as namespace names.

Yes indeed. It should very clearly say something about
this topic.

>I think the simplest way of resolving the possible
>contradiction would be  disallow hex-escaping in
>IRIs used for namespace names.

That would be one possible solution, and a very clear
one. There are a few details to be worked out.
For example, do we want to disallow all %-escapes?
Or %-escapes above %7F? Are there any legacy namespaces
that we have to care about?

>More generally, it would be a good idea to strongly
>discourage the simultaneous use of multiple URIs
>or IRIs that might, for some applications, be considered
>   http://www.example.org and http://www.example.org/
>should not both be used as namespace names even
>though they are not string-equal.

I fully agree with this, and think that this should
be fixed when going to Proposed Recommendation with

Regards,    Martin.
Received on Wednesday, 5 February 2003 12:45:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:27 UTC