Lists Home |
Date Index |
On 2002-02-13 22:56, "ext Paul Prescod" <firstname.lastname@example.org> wrote:
> John Cowan wrote:
>> Fair enough. But one and the same URI should not name two different
> Agreed. The question is whether *you* can have a URI which, when someone
> does a GET on it, returns an HTML page. I don't see why not. We can
> agree that there can be an RDDL document at a namespace URI without the
> HTML document *being* the namespace. It is one representation for the
> namespace. Another might be a pure HTML rendition, another a schema etc.
> conneg allows this possibility to be concrete, not abstract.
The problem here is that if I dereference some URI expecting to
access that actual resource, and get some metadata or RDDL document
or something else in its place, how do I necessarily know that
that is *not* in fact the resource? It may not actually be apparent
from the mnemmonic qualities of the URI, and such qualities are
unlikely to be meaningful to some software application.
Just as when using HTTP URLs to denote abstract resources, a 404
error is not really an error, but an inevitable outcome; likewise,
returning anything at all for an abstract resource appears to
be a success, but in fact is not, since you actually didn't get
the resource denoted by the URI (and cannot get it) and some
application (not a human) may think it did.
Thus using HTTP success or failure as a basis to determine if a
given URI does or does not denote a web-accessible resource
cannot work reliably.
It should be clear up front what "flavor" of URI you have, and
whether it does or does not denote some retrievable resource
or whether it denotes some abstract resource -- or if it is
in fact the actual resource (consider a data: URI). And that
should be based on a formal classification of URI schemes and
With that knowledge, an application can know that 404 really
is an error and need not bother to resolve URIs denoting
abstract, or actual resources.
Patrick Stickler Phone: +358 50 483 9453
Senior Research Scientist Fax: +358 7180 35409
Nokia Research Center Email: email@example.com