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

Dare Obasanjo writes:

>> Hopefully if the architecture document 
>> says anything in this direction
>> it will lean away from URI opacity.

My suspicion is that merely saying "yes, opaque" or "no not opaque" will 
prove to be suboptimal.  My guess is that the better answer will be along 
the lines that URIs should be completely opaque for certain purposes, 
should (perhaps) be opaque after the scheme name for certain other 
purposes, and should have parseable structure for certain other purposes. 
I hope the TAG will provide some guidance on the whens and wheres.

>> 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. 

My intuition runs in the other direction.  I do believe that some serious 
architectural work is needed to figure out the conventions for versioning, 
evolving, and bug-fixing vocabularies, namespaces and the corresponding 
schemes.  My intuition is that encoding version control information in the 
namespace names themselves is probably not the right way to go.  Anyway, 
I'd prefer to see some general principles on URI opacity set out 
independent of namespaces in particular.  If appropriate, one could also 
discuss the application to namespaces;  unlike you, I tend to feel that 
namespace names are indeed a situation where URI's should be completely 
opaque, right down to ignoring the potential equivalence of 
http://example.org and HTTP://example.org.  Your mileage may vary.

------------------------------------------------------------------
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 23:37:12 UTC