RE: I-D ACTION:draft-daigle-uri-std-00.txt

> Abstract concepts don't have to be that airy.  Nouns aren't,
> for instance,
> and the noun to which 'New York' refers changes every second
> of every day.

'New York' is an identifier that identifies a fuzzy thing that changes all
the time and looks different to all people. At some abstract level,
however, we all agree on that it is something that looks like a city on
the US east coast.

A URI is an identifier that identifiers abstract resources that may change
all the time and may look different to different people.

What's the difference other than the generalization?

> If I describe the namespace URI "http://www.w3.org/1999/xhtml", am I
> describing the entity body (a resource, I think) stored at
> that address?
> Am I describing a 'namespace', something which exists purely in the
> abstract?  Am I describing (as I think would be intended)
> XHTML itself?
> We've had very different answers on xml-uri, and I'm not
> convinced that the
> flaws are on the XML side of the equation.

Resources are first class objects - you identify them using URIs. When
describing or talking about a resource, you use the URI to refer to that
resource.

You can never get to the resource - you can get a manifestation of the
resource - for example by performing an HTTP GET request on it. A resource
can have any number of manifestations - think of each manifestation as a
snapshot of a living thing: you can take as many snapshots you like - some
may be the same and some may not.

> The URI opens possibilities, but it provides no way to choose
> among those
> possibilities.  This isn't a problem peculiar to Namespaces
> in XML, either.
>  It arises any time you need to describe a resource or a URI,
> since the two
> are effectively blurred by the practices enshrined in RFC 2396.

I don't believe it mentions anywhere that you are describing URIs because
that wouldn't make sense.

> On a more mechanical level, I think the xml-uri discussions
> have made it
> clear that rules for comparing URIs are broken at worst,
> contested at best.
>  Providing a baseline comparison that could be used across
> schemes - even
> at the cost of false negatives - would have made all of this
> much easier.

A baseline comparison is exactly what RFC 2396 defines - you keep saying
this - what is it that you don't see defined?

Henrik

Received on Thursday, 7 September 2000 11:35:24 UTC