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

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

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

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

Received on Thursday, 7 September 2000 08:07:30 UTC