- From: Sean B. Palmer <sean@mysterylights.com>
- Date: Tue, 6 Nov 2001 17:54:31 -0000
- To: "Aaron Swartz" <me@aaronsw.com>
- Cc: <uri@w3.org>
[...] > 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