W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: The questions and their relationship

From: John Aldridge <john.aldridge@informatix.co.uk>
Date: Fri, 19 May 2000 12:11:30 +0100
Message-Id: <4.3.1.0.20000519114220.02454a80@mailhost>
To: abrahams@acm.org, xml-uri@w3.org
At 15:01 18/05/00 -0400, Paul W. Abrahams wrote:
>The questions I'm seeing are:
>
>1. Should relative URIs be disallowed, possibly through deprecation, as
>namespace names in the sense of the Namespace Specification?
>
>2. When comparing URI's for equality, should the comparison be based on their
>literal string representation... (snip)
>
>3. Should the URI reference in a namespace attribute point to a resource of
>some kind... (snip)
>
>Does that cover the principal questions we're examining?   Are the answers
>independent, as it seems to me they are?

I don't think they are independent.

It seems clear to me that several people believe that, although the 
namespace specification _itself_ does not require URI dereferencability, 
the "right thing" is for higher level specifications (such as schemas) to 
assume their dereferencability in the context of that higher level 
specification.

_If_ you believe that dereferencing namespace URIs in order to retrieve 
information about the namespace (e.g. a schema) is going to be the norm, 
then I think it follows that using literal string comparison as a basis for 
namespace identity is a bizarre strategy.  It leads to the same namespace 
having different meanings dependent on where it's used, which surely 
defeats the whole point of the exercise.

_If_, on the other hand, you believe that using a URI to identify a 
namespace is simply a handy way of avoiding name clashes, and that 
information about the namespace will be retrieved by looking up the this 
URI in some catalogue, then literal string comparison is perfectly 
appropriate.  In this view, using a GUID or FPI to identify a namespace 
would have been equally good as a solution.
--
Cheers,
John
Received on Friday, 19 May 2000 07:12:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC