W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

RE: URI Opacity Principle (was: Re: use of fragments as names is irresponsible)

From: Dare Obasanjo <dareo@microsoft.com>
Date: Tue, 14 Jan 2003 19:49:31 -0800
Message-ID: <B885BEDCB3664E4AB1C72F1D85CB29F804B7C7F5@RED-MSG-10.redmond.corp.microsoft.com>
To: <noah_mendelsohn@us.ibm.com>, "Sandro Hawke" <sandro@w3.org>
Cc: "Roy T. Fielding" <fielding@apache.org>, <www-tag@w3.org>

Hopefully if the architecture document says anything in this direction
it will lean away from URI opacity. The opacity of URIs is a problem for
in XML application, specifically those that use XML namespaces. A number
of issues that come up in XML applications would be a lot easier to
solve (e.g. how does one version XML namespaces?) if namespace names
were structured and not just glorified UUIDs. 

The ideal vacation cottage is one that visits twelve but sleeps two.

This posting is provided "AS IS" with no warranties, and confers no

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: Tuesday, January 14, 2003 7:38 PM
> To: Sandro Hawke
> Cc: Roy T. Fielding; www-tag@w3.org
> Roy Fielding writes:
> >> Somewhere along the line the W3C got hooked on the notion 
> that URIs 
> >> are opaque and hierarchy is meaningless.  That is bogus, 
> as evidenced 
> >> by every decent information site on the web today.
> As I think I've suggested once or twice, the TAG would do the 
> community a service IMO if it would clarify the degree to 
> which URI's are indeed to be 
> viewed as opaque.   When may their substructure be either 
> inspected or 
> built up incrementally, and when are they to be treated as 
> "black boxes"?
> Tim BL provides one exposition of the opacity principle at 
> [1].  In general, I find that many correspondents on this 
> list and others both oversimplify and confuse the issues, and 
> one can make the case that the principle has not in fact been 
> stated sufficiently clearly (or, per Roy's note, perhaps it 
> is at times a false goal).  Surely it is confusing to hear on 
> the one hand that URIs are opaque, while on the other RFC 
> 2396 [2] goes to some length to provide hierarchical 
> substructure as a special case.  There is surely a sense in which:
>         uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
> is more inherently opaque (assuming the "-"s are truly just for
> readability) than:
>         http://example.org/root/sub1/sub2/mydoc.html
> If URI's were really intended to be opaque, why not make most 
> every URI a uuid?
> My impression is that the server implementing an HTTP 
> resource should indeed have the ability to process based on 
> the substructure of the URI. 
> Surely it is appropriate for the server to map the HTTP 
> example above to file system sub-directories should it choose 
> to do so? (Though of course, that's not required or visible 
> from the outside.)  Is it OK for a client to help you build 
> up the URI incrementally, one piece at a time?  IE does. 
> Is it OK to build a query string in a URI from a form?  
> Pretty surely, and Tim says so.  Is it OK for a client 
> history list to gather all the URI's that seem to be from 
> example.org and group them?  Common practice suggests "yes".  
> Can proxies cache based on the substructure of the URI?  I 
> would think that's desirable (but don't try it with the uuid: 
> scheme).  Is it OK to start guessing MIME types of 
> representations from that .html at the end?  True believers 
> seem to say no (and I guess I'm one of them).  Is it OK to 
> assume that the .html URI above references a Web page as 
> opposed to some human being associated with a web page as 
> opposed to some human being who has nothing to do with a web 
> page?  Seems to be the fodder for lots of rambling on this 
> list.  When is it appropriate for a client or other agent to 
> inspect the scheme as a means of determining a retrieval 
> strategy?  I'm still somewhat confused as to what folks such 
> as Roy think on this one, since we often hear that HTTP: need 
> not identify resources to be retrieved with HTTP (or maybe 
> I've misunderstood).
> Anyway, I don't claim to have the answers, but it's very much 
> the sort of question I would expect the architecture document 
> to help settle.  Just saying "URI's should be opaque" seems 
> too simplistic, and thus confusing. 
> I'm glad Roy's note has brought it up.  Thank you!
> Noah
> [1] http://www.w3.org/DesignIssues/Axioms.html#opaque
> [2] http://www.ietf.org/rfc/rfc2396.txt
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
Received on Tuesday, 14 January 2003 22:50:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC