- From: Mike Brown <mike@skew.org>
- Date: Thu, 2 Sep 2004 15:07:08 -0600 (MDT)
- To: Kitchen.Pages@chilled.skew.org, computer software <jrobinson@kitchenpages.com>
- CC: uri@w3.org
Kitchen Pages wrote:
> Just a short quickie question
I see various question marks in your message, but no actual questions, at
least none that I can follow well enough to provide an answer for. I suspect
others on the list haven't responded because they feel the same. What is your
quickie question?
> The text below is from one of my books on how to use/programme for BCB
> c++ (Borland Builder) published in 1998 which states:
At the risk of sounding like Roy Fielding, whatever (mis-)understandings you
have picked up from that book, or from anywhere other than the RFCs
themselves, are irrelevant. A book about some programming language can say
what it wants about anything. I tend to assume that the actual specs are going
to be more accurate and precise than the executive summary you get in a book,
especially if the topic is peripheral to the main topic of the book.
That said, the concepts that the URI generic syntax embodies have been refined
over time, influenced by the nuances of HTTP and the kind of situation
described in the Borland book you quoted. Resource has been decoupled from
representation, and identification has been decoupled from retrieval.
Consequently, a clear distinction between a "locator" and a "name" is not
necessary to maintain at either the syntactic level or the semantic level, for
the purposes of resource identification.
Location may be important in the definition of a scheme, for implementation,
but even in the case of the http scheme, location is only relevant in a URI's
authority component when one is using a resolver that uses that component in
the usual manner, dissecting it into a host, port, and userinfo, and talking
over a network -- it could just as easily use a catalog instead, effectively
treating the http URI as an opaque identifier rather than having any location
semantics implicit in the URI at all.
> In a nutshell as I am - I was wondering ? that perhaps the URL
> references used in the draft text could be stated; like an RFC number
> as the "Informative References" seem to have multiple choices which may
> not be a bad thing but it is somewhat confusing considering the
> reference to REC2141 for URN (or should I use that?).
I can't figure out what you're referring to ("the URL references"?), what
you're asking for ("stated"? "use RFC 2141 for URN"?), or what your complaint
is, exactly, with the current draft.
If you have an editorial suggestion for improving the Informative References
section, then my advice would be to please try to state it clearly, for better
results: "RFC 2396bis draft 06 currently says..., which is confusing
because..., and here's what (or the kind of thing) it could say that would
mitigate that confusion..." ...then prepare to be roasted by Roy. :)
-Mike
Received on Thursday, 2 September 2004 21:07:10 UTC