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

On Thu, Sep 07, 2000 at 08:10:37AM -0400, Simon St.Laurent wrote:
> >  I assume that for your applications you need some further constrained
> >definition of what a Resource is. That's fine. But are you suggesting
> >that your definitions be applied to other applications as well?
> 
> I'm suggesting that the URI community stop hiding behind 'a resource is
> anything you can identify' and start talking about what resources are.

Why? A lot of us in other application arenas are perfectly happy with that
definition and would prefer to keep it that way. Anything more constraining
starts to put unnecessary controls on what someone can do with a URI
and thats something we very explicitly _don't_ want to do.
Take a look at http://www.ietf.org/internet-drafts/draft-ietf-cnrp-uri-02.txt
for an example of how others view what URIs are capable of.

> 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.

The abstract concept of 'number' is pretty airy. The concrete case of
'positive integers' is fairly well constrained. The concept of URIs
should be viewed in the same level of the concept of 'number' and the
general case of 'number theory'. If your application needs the equivalent
of 'positive integers' then say so. Why do you insist on the rest of
us having to constrain ourselves to that new, more constrained definition?

I'm well aware of the issues that some of the applications you care about
have with the general case of URIs and I sympathize. I share your
views that the case of the 'http' scheme being a 'generalized namespace' 
is vastly distorted and in many cases dangerous (just my personal opinion)
due to its perceived uses and lack of rigorousness about its language.

In that case my suggested solution to you is to not attempt to redefine
the entire space of URIs to adhere to your needs. Instead _design_ a 
new scheme that does. That's why we kept the entire generalized concept
of URIs 'airy'. Its so that you can come along and design a scheme that
does exactly what you want without having to inherit a lot of semantics
that are incompatible with your application. Then further specify 
that the application only works with a certain subset of the URI space.

IMHO, I think such a scheme would have a lot of practical uses outside
your application. I also think that URNs might possibly satisfy them but
I'd have to sit down and have an extended conversation just to find out....

-MM

> The definition below starts off well, but quickly sublimates into invisible
> gas. 
> 
> >Resource
> >A resource can be anything that has identity.  Familiar
> >examples include an electronic document, an image, a service
> >(e.g., "today's weather report for Los Angeles"), and a
> >collection of other resources.  Not all resources are network
> >"retrievable"; e.g., human beings, corporations, and bound
> >books in a library can also be considered resources.
> >
> >The resource is the conceptual mapping to an entity or set of
> >entities, not necessarily the entity which corresponds to that
> >mapping at any particular instance in time.  Thus, a resource
> >can remain constant even when its content---the entities to
> >which it currently corresponds---changes over time, provided
> >that the conceptual mapping is not changed in the process.
> 
> A lot of the problems raised on the xml-uri list seem to have to with the
> fact that a resource 'can be anything that has identity' makes it very
> difficult to separate the identifier from the resource in usage where only
> the URI is available.
> 
> 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.
> 
> 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.
> 
> 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.

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

Received on Thursday, 7 September 2000 08:41:52 UTC