URI's in namespaces

[Dan Brickley]

On Wed, 24 Nov 1999, Jeffrey E. Sussna wrote:

> Not to rouse the fitfully sleeping namespace beast, but I can't get it out
> of my mind. In particular, I have a dumb question:
> 
> If the namespace facility designers were adamant that a namespace identifier
> doesn't necessarily point to any actual schema, then why did they use URI's
> as namespace "targets". The whole notion of URI implies that there's
> something (i.e., the resource) out there. But a namespace is not inherently
> a pointer (regardless of whether you can access the thing pointed to). Why
> not just make namespace targets ordinary XML names?

On the Web, everything of value and interest has a URI so we can talk
about it. That's just the Web information model. Some URIs encode
meta-information about how to connect to a service to find out more
about (and possible acquire views or renderings of) the named resource.

The relationship between URIs and "bags of bits" is not as
simple as is often implied within the namespace debates.

A URI is more than simply a pointer to a bag of bits. The Web makes it
easy to think of URIs in this way, but usually there's something more
complex and subtle going on.

Content negotiation is the classic example:

http://www.w3.org/Icons/WWW/w3c_main is the name of a resource. That
resource is an 'abstract' thing (a logo) without an intrinsic byte-stream
representation of its own. That abstract named work, the logo, has
concrete manifestations in two other name-able resources, w3c_main.gif
and w3c_main.png. 

Because the identifier for the abstract resource encodes information
sufficient to put clients in touch with an authoritative service that
knows about that resource, we can "ask the Web" for information about
w3c_main. Current HTTP/1.1 is a bit hacky in this
respect, but does have the notion of content-negotiation, exploited
below. 

If a web client does an HTTP GET on w3c_main you'll get a bag of
bytes, since the machinery will figure out that you're after one of the 
content-negotiable renderings. If however you send a HEAD message to
www.w3.org's HTTP server, qualified with an "Accept" mimetype preference
asking for a non-existant rendering of the resource, you'll get a bunch
of metadata back.

Here's an HTTP session transcript where I ask for info about a
(non-existent) rendering of the logo resource, which prompt Apache to
spill some details about the versions that are available.

	[danbri]$ telnet www.w3.org 80
	Trying...
	Connected to www.w3.org.
	Escape character is '^]'.
	HEAD /Icons/WWW/w3c_main HTTP/1.1
	Host: 127.0.0.1
	Accept: application/x-fictitious-mimetype
 
	HTTP/1.1 406 Not Acceptable
	Date: Wed, 24 Nov 1999 22:42:53 GMT
	Server: Apache/1.3.6 (Unix) PHP/3.0.11
	Alternates: {"w3c_main.png" 0.7 {type image/png} {length 5904}},
	{"w3c_main.gif" 0.5 {type image/gif} {length 5684}}
	Vary: negotiate, accept
	TCN: list
	Content-Type: text/html


What does this show? That an globally unique name for something is
useful, and that the abstract name can map onto multiple
(metadata-described) mime-typed bags of bits  that are also resource
with URIs,  and that we have protocols in place to ask the Web about
both abstract and bytestreamable resources, and to negotiate access to the latter.  

It does not follow from the fact that we name something 'http:*' that it
is a Web page, or that it has only a single manifestation on the network
as a load of bits, or that you have the right to access any or all of those
bytestream renderings. Dereferencing being a privilege not a right and
all that...

I could create an XML vocabulary, name it (say) 'http://xmlns.com/foo',
and configure my server to understand content-negotiated GET and HEAD
requests. This doesn't make 'http://xmlns.com/foo' a simple pointer to a
mimtyped bytestream. While the resource (an abstract work, _just like_
the W3C logo http://www.w3.org/Icons/WWW/w3c_main) is certainly "out
there" in some sense, the fact that we can (when the wind is blowing in
the right direction, network is up, access control is liberal etc etc)
ask an HTTP server about that abstract resource is a feature not a bug.

Dan


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)