Re: Common Sense! Was: Re: The 'resource' identified by a namespace name URI should be the namespace

At 11:44 AM 2000-06-03 -0400, Clark C. Evans wrote:
>
>On Sat, 3 Jun 100, John Cowan wrote:
>> Tim Berners-Lee scripsit:
>> > We are losing track of reality. 
>
>Exactly.
>
>> > A mailto: URI necessarily identifies an internet mailbox.  A mailbox
>> > is a mailbox. A namespace is a namesapce. A mailbox can be a
>> > group-mailbox. A mailbox can be a personal-mailbox.
>> > A mailbox can NOT be a namespace.
>> 
>> Neither can a (text, hypertext, hypermedia) document BE a namespace.
>> Not even if it contains an XML Schema document.
>
>Exactly, if it looks like a duck, it is a duck.  Anything 
>short of it being a duck is impractical for 90% of us
>dumbells out here.  

Yeah, but 'namespace' is not comparable to 'duck.'  More like 'biped.'  Not
even 'feathered biped.'  The quacks all go with subcategories of
'namespace.'  In reality, namespaces are mostly non-entities.  Identify the
actual entity [like XSLT] the namespace comes from or is associated with.
That's where you'll find a little more reality.

>
>This is the first bit of "common sense" I've heared in a
>long time.   This leads us to a single, obvious suggesion:
>
>1.  Define a new URI which is explicity for namespaces
>    define its qualities so that it works as we 
>    expect a namespace to work (uniqueness); and such 
>    that it has no additional connotations (that it is 
>    a mailbox or a hypertext or raw-data, etc.)   
>
>    I suggest the java package style...
>       "xmlns:com.clarkevans.timesheet"
>
>2.  Deprechiate all other URI forms, set a 5 year phase out
>    period; this should be enough for a slow transition.

1. and 2. classify things along the wrong lines.  Namespaces as presently
defined are frequently not what you want to identify and refer to.  There
is no need nor is it a good idea to move on this front until point 4. below
has been worked out.

Where a namespace is a captive feature or byproduct of a defined entity
[e.g. the XSLT language] it is questionable to treat it as an entity
meriting an identity of its own.

>3.  Until (and after) the phase out, treat NS comparison
>    as the current spec says, a byte-for-byte comparison.

This is still a good idea, within a suitable definition of lower-layer
processing.

>4.  If someone wants to associate a XSchema or RelaxSchema
>    or some *other* non-namespace resource to a namespace,
>    then let that specification define such a binding.

Yes.  There may be several documents, each illuminating a different aspect
of the namespace [i.e. the proper knowledge or connotations of the
namespace].  The relationship is a characteristic of the class of schema or
other dictionary document.  That is an open field for extension.

On the other hand, there is an appropriate short circuit in the case where
the binding is be definitive [as with XSLT], i.e. the document may create
and definitively describe just one namespace, in which case a reference to
the document is suitable as an identifier for the namespace.  In this case
the document itself defines a 1:1 relationship between namespace and
document and in identifying the namespace a reference to the document is
definitive.  The document has a unique proper namespace and the
identification is clear.

Al

>
>This would end a whole slew of debates and draw 
>us to a reasonable close.

>
>Clark
>

Received on Saturday, 3 June 2000 17:10:00 UTC