Re: Excess URI schemes considered harmful

[...]
> While this is certainly true, and may be useful, it seems to
> ignore the foundational ideas of the Web.

If it is both true and useful, and yet contrary to the "foundational ideas
of the Web", then it doesn't seem as if the "foundational ideas of the Web"
that you speak of are all that useful. Perhaps what you mean is that it is
only useful up to an extent, viz. that on a small scale it is useful, but
on a large scale, more harmful.

[...]
> The benefit of URIs was that they were _Uniform_ -- they
> have a well-defined way of creation, definition and a binding
> of some sort to Resources.

And URI references don't? They must map to *something*, have some utility
or purpose, and as a resource can be anything, they must map to candidate
resources. It's easy to import URIviews into URI space [all undefined
components imported from RFC 2396]:-

   URIview = absoluteURI "#" fragment
   newURN = "urn:urn-n:" fragment ":" absoluteURI

Er... actually, it would have to be fragment-colon, but I can't be bothered
to give the BNF for that. The principle is clear, that I can easily import
URIviews into URI space, such that what these new URIs denote is the
"thing" denoted by the URIviews. It's acutally a pointless excercise,
because URIviews already denote these things. The question is, "what subset
of resources do they identify?", not "do they identify resources?".

[[[
   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result.
]]] - RFC 2396

I'm a bit wary of the language there... it may be possible to deliver data
that is typed on other ways than MIME, so I take "media type" to be used in
its broadest sense. Of course, for future extensibility, we would hope not
to be limited to some pretty out-of-date typing method lying about in some
old RFC. We can't tell what sort of things we might be sending over the
"wires" in future; the whole notion of "media type" may get rather twisted.

> But, not all of this holds true for URI-references. They're
> mapping to Resources does not follow the spec,

That's rubbish - the specification doesn't really give a clear indication
of what they map to, but the definition for "resource" indicates that they
still map to some sort of resource.

> their creation and definition is unclear,

Once again, this is simply not true: the specification delegates provision
of semantics of fragments to the designers/creators/definers of new "media
types". The same way that it delegates provision of semantics of (for
example) HTTP URIs to the HTTP specification, or FTP URIs to the FTP
specification.

Just because the UA gets to interpret the "semantics" of what the fragment
represents, that doesn't mean that it is necessarily any less clearly
defined. XPointer is very, very, clearly defined. I can quite easily point
to an entire element in an XML document... and that element is a resource.
The semantics of that fragment are controlled by the XPointer
specification. UAs can choose not to implement it, in the same way that
they can choose not to implement HTTP GET.

> and they are not supported by HTTP or other protocols.

Correct. Why would they be?

> This is why I don't understand why some insist that
> URI-references are just as good as URIs. If this is true,
> why not random strings, or any sort of binary data?

Well of course you can use random strings or binary data! URIs don't have
to be the only universal information space, but all universal information
spaces should be able to subsume one another. It is also possible to have
non-URI identification schemes that reference very clearly a set of
resources that aren't clearly in URI space (but can be). This is the case
with URI-References.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Tuesday, 6 November 2001 12:55:24 UTC