Re: The 'resource' identified by a namespace name URI should be the namespace

At 01:42 PM 2000-06-01 -0700, Larry Masinter wrote:
>> This is explained, in of all places, the namespace rec. The purpose of
>> xml namespaces is to define xml names such that they have scope
>> "beyond their containing document" (presumably to the universe, given
>> your three choices).
>> 
>> This is accomplished by giving the namespace a name which is a URI uri
>> reference and you can make sure the name is unique by using an
>> absolute URI of a resource you control. (but using the URI as the
>> namespace name does not mean that the resource _is_ the namespace)
>
>
>I think that you get into trouble allowing arbitrary URIs as namespace
>names, and that the world would work better if it was stated that the
>'resource' identified by the namespace name is 'the definition of
>the namespace'. 
>
>Since we currently have no technical means to define a namespace other
>than to identify it, there is no expectation that a namespace name
>be a URI that is dereferencable.
>

There is no end _today_ of ways to define namespaces, or give information
about said namespaces.  XML DTDs, RELAX, Scematron, the XHTML 1.1
documents, etc. do the trick.  These range over various degrees of
formality.  I am not entirely sure what you wold credit as 'technical.'
There is none of these that is recognized as specifically appropriate or
uniquely appropriate by any consensus or plurality of the XML community or
by any XML specification recognized as normative by any such preponderance
of opinion.

On the other hand, it is dangerously closed to think only of resources
_defining_ a namespace, as if the namespace were a closed thing with a
definitive set of proper knowledge.

This is part of the reason why the ns-attr is not a whole solution to the
problem; there can be lots of resources which tell you things about the
namespace, usable in different processing plans and advantageous to
different ends.

The whole matter can be handled [without incompatible change to the NS Rec.
proper] with a vector of X-Link's iff we can come to some consensus through
a DC-like process on what a variety of relationship descriptions are which
will a) be loose enough to allow some variability in the way that the pair
(self, indicated resource) fits the relationship descriptor and b) yet be
precise enough so that we when we have multiple related resources to cite,
we can mark the multiple references in a way which will support intelligent
choice without recovery of all the cited resources.  If the relationship is
more baroque than that and the document needs to disclose this, then a
logic language insert to clarify the same is appropriate.  The reader of
the current document, from the citations in that document, should be able
to get a pretty good idea of the respective gain and pain of applying each
cited item as a co-resource.  Gain is measured in what performance is
improved if you add this processing (and optionally how much); pain
involves what other resources you have to bind to, to exploit this one; the
language or type of the resource; and the like.

Al

> 
>

Received on Thursday, 1 June 2000 18:10:30 UTC