Re: The 'resource' identified by a namespace name URI should be the namespace

On Thu, 1 Jun 2000, Michael Mealling wrote:
> > I like this notion; however, it would only work if the relation
> > which maps a set of URI to a set of resources is an injective 
> > (1-1) function.  Otherwise, one may have two URI in the set
> > which map to the same resource ... which would violate the
> > "uniqueness" requirement and necessitate something smarter
> > than a byte-by-byte URI comparison.
> 
> I'm not sure if I ever got a definition to how your using 'same' here...

The definition of same depends upon the scheme in question.

For the http scheme, the typical use is to fetch the resulting 
entity.  We could debate which is the resource, the entity 
returned; or the service which would produce the entity returned.  
In either case, one could reasonably define 'same' for the http 
scheme as the entity returned.  

> Again we come back to this. Where is this injective quality
> required?

The injective quality would be needed if "[t]he 'resource' 
identified by a namespace name URI should be the namespace".

> In the document the characteristics of uniquenesss 
> and persistence apply to the name, not the resource.

As defined by the namespace specification, yes.  However, 
this was not the context of my reply.

> I still can't figure out what possible feature depends on this
> requirement....

Assuming that "[t]he 'resource' identified by a namespace name 
URI should be the namespace", there is two ways to garuentee
the uniqueness required for a consistent naming space:

  a) define 'same' for the resource and compare resources

or
  b) insist on an injective function from the URIs used into
     the resources identified.

Of course... we just define the namespace *as* the URI
and avoid the whole resource issue.  Right?  At least
until we start to dally with relative URIs.

> > As Tim BL has stated, this injective property does 
> > not hold for many URI schemes, including the commonly
> > used http scheme. However, not all is lost.  The spec 
> > could be modified to clearly describe a set of URI 
> > schemes which do have the injective property.  The 
> > "data:" scheme is one such example.  We could even define
> > a java package like scheme; "package:com.clarkevans.my-ns"
> 
> I've heard you claim more than once that Java package names
> have this injective quality but I can't see how. 

(a) The Java specification defines package comparison in
    terms of character for character of its names. 

(b) I would assume that creating a new URI we could define
    'same' *at the URI scheme level*.

Unfortunately for the namespace specification
(specifically the examples using the http scheme), 
an http URI "quacks like a duck".   It came with its 
own notion of 'same' which is different from the 
namespace specification of 'same'; and even seems
to differ based upon who you ask...

> > One could go even further and include restricted versions
> > of more common URI scheme.  For example, define the "namespace
> > acceptable sub-scheme for http:" as:
> >   
> >   { uri in http: such that for each namespace
> >     resource, there exists at most one http:
> >     uri that identifies that resource }
> 
> And this accomplishes what? Your assertion is immediately violated
> by using the IP address of the host instead of the domain-name.
> They both identify the same variously represented resource...

I am explaining a sub-set of the URI in the http scheme that
is consistent -- has an injective (1-1) function from the URI
space into the resource space.

For example, given a resource X with an absolute http scheme 
URI Y.  Let Y' be the URI obtained by replacing the host name
with the IP address found through the nslookup function.
Since Y != Y'  and since resolve(Y) == resolve(Y'), we know
that both Y and Y' cannot both be in the same "acceptable
sub-scheme" as described below.

There is no assertion violation.

> > Note:  Unless I am mistaken, this is actual practice.  
> > There is one and only one http: URI which corresponds 
> > to the XSLT namespace.  

To this, John Cowan wrote:

> This is badly worded.  Actual practice is to choose one of 
> the many possible URIs which identify the namespace and use 
> that form exclusively as the namespace name.

Yes.  This is a way to actively construct such a URI 
sub-scheme which has the injective property; and it
is being used and works today.    

On Thu, 1 Jun 2000, Tim Berners-Lee wrote:
> > Without the uniqueness constraint, R1 == R2 
> > implies u1 == u2, one cannot [always] acertain 
> > if the two URI given identify the same resource.
>
> On the contrary, you can indeed acertain that two 
> URIs given identify the same resource. What
> you cannot do is acertain that they don't.

Ok, I forgot the "always" before my "cannot".

Given any two URI, u1 and u2, such that u1 != u2.
Without the uniqueness constraint (injective 
property of the resolve function), one cannot
prove if the following is true or false...
  resolve(u1) == resolve(u2)

And this I feel is problematic...  isn't it?


Best Wishes,


Clark

Received on Thursday, 1 June 2000 19:51:00 UTC