Reasons to use namespaces

At 12:16 PM 6/8/00 +0100, David Carlisle wrote:
> > Ignoring, for now, issues of relative and context-dependent URIs.  If a
> > namespace is a resource, and a namespace name is a URI:  what resource is
> > identified by that URI?  Logically, it is the namespace
>
>"logically" is rather a contentious word to use:-)

Sorry, best I could come up with :-)

>Some people have the mistaken belief that namespaces and schema are
>effectively the same thing, ...

I've not detected such belief held explicitly.  My concern is that it might 
be an unintended logical consequence of the other desiderata 
expressed.  (And this time I _mean_ "logical" :-)

> > There is, I think, a related issue:  I had thought that content 
> negotiation
> > might be used to select different representations of a schema associated
>
>How would content negotiation distinguish which of the 5 or 6 so far
>published schema (dtd) for the xhtml namespace you want to use, or
>which of the arbitrary many schema for the same namespace that you can
>create using xhtml modularisation?

When one does a "GET", or equivalent operation, on the resource URI, 
indicating what are acceptable versions of the resource;  e.g.
    Accept: text/html            -- for the document describing the schema 
language
    Accept: application/rdf-xml  -- for the RDF schema

    (etc.)
Any of these might be reasonable versions, or "renderings", of the 
semantics bound to a schema identifier.  (The use of accept and 
content-type's here is merely illustrative -- a practical negotiation 
scheme would need to be more subtle.)

But this view requires that specific schema documents are accessible as 
_part_ of some more abstract semantic resource, possibly as well as 
distinct resources in their own right.

> > I think a basic formal algebra of URIs and resources might help to set
> > some of these issues in place.
>
>If there is no agreement on whether namespaces are the resources
>identified by the URI used as the namespace names then I don't see how
>any such algebra is going to help.

In my previous response to Al Gilman's posting [1], I tried to explore 
separating the use of a namespace name as simple mechanism for syntactic 
discrimination between namespaces used from the more demanding goal of 
providing sufficient information to identify some associated semantics 
("binding to semantics" was Al Gilman's phrase, which I interpret 
differently than "retrieving a schema").

Within web architecture as I understand it, treating the namespace as a 
resource is the favoured way of binding to semantics.  Absent this goal, 
then the (appropriately distinguishable) name of any resource would seem to 
be sufficient, as you say.

But, a formal algebra may help to make it clear what additional 
requirements must be imposed on such URIs if they are to serve the 
additional purposes of binding to semantics, IMO.

>I claim http://www.dcarlisle.demon.co.uk is the URI representing
>the "home page" of myself and my wife. Since I pay to have that
>URI work, and I wrote the page in question, I think it is reasonable
>for me to assert that that is the resource identified by that URI.
>
>Now any namespace processor, without having read the above paragraph
>has to decide what to do with
>
><x xmlns="http://www.dcarlisle.demon.co.uk"/>

[...]

>Tim Berners-Lee and Dan Connolly have asserted that my doing that
>is somehow wrong, but no one has ever suggested any change
>that would make that wrong. Or what the namespace processor is
>supposed to do to reject the document.

My view is that that's fine if all you want to do is syntax-level 
distinction between namespace prefix usage in some documents.

But if you want to do more --have some globally accessible meaning 
associated with use of the namespace-- then the choice of your home page 
URI is inappropriate.  I happen to think that this kind of binding to 
semantics is a supremely important goal for the future of networked 
information.

<soapbox>
Or:  should semantics be bound to the data, or to the application that 
processes the data?  Currently, mostly what we do is the latter, but I 
think that approach is not ultimately scalable.  Should the data dictate 
what applications I can use to process it?  The Internet has given us an 
end-to-end architecture for communications, and witness the explosion of 
possibilities that has brought.  But what about content?  Should its 
meaning be bound up in the murky innards of the specific applications that 
generate and process it, or should it be open to new uses by new 
applications?  Where is our end-to-end architecture for content?
</soapbox>

The reason for my <soapbox> is to suggest that there may be some really 
compelling reasons for looking beyond the literal interpretation of 
namespace matching in the namespace REC.

Having said that, I find myself wondering if "fixing" the namespace REC is 
the best way forward.  If there is a constituency for whom it serves a 
useful purpose, why change?  Maybe, a new document that explicitly 
addresses some higher goals and sets out additional constraints on 
namespace usage that must be observed to address those goals might be a 
more productive approach?

#g
--

[1] (Working offline, so no archive URI -- sorry.)
     Date: Sat, 03 Jun 2000 17:17:10 -0500
     To: <xml-uri@w3.org>
     From: Al Gilman <asgilman@iamdigex.net>
     Subject: Re: stepping backward (one more step)


------------
Graham Klyne
(GK@ACM.ORG)

Received on Thursday, 8 June 2000 11:56:14 UTC