Namespace names: a modification of a semi-serious proposal

Mixing Eric's notion of package names, Paul's notion of
deprechiating all but a "uuid:" mechanism, and John Cowan's
post about using the "data:" URI mechanism.  I suggest...

    <ce:myxml xmlns:ce="data:com.clarkevans.cce" />

On Sat, 27 May 2000, David Carlisle wrote:
> You propose to change namespace names so that instead of it not 
> being a goal that the namespace name is directly used for retrieval,
> instead  it is impossible to use the name for retrieval.

Correct.  For backwards compatibility, re-write all of the examples
to use "data:" and then deprechiate use of any other URI type!

> But I don't see how it is going to please the people who are unhappy
> that they can't currently use the namespace name to directly locate
> information about the namespace.

Ok.  As a compromise....

    DEFINE NAMESPACE EQUIVALENCE AS A BYTE-FOR-BYTE COMPARISON
    OF THE RESOURCE AS RESOLVED *AND* RETRIEVED.

  For "data:" it works exactly as the authors of the namespace
  recommendation had suggested since the resolution of the URI
  is the text immediately following.   

  For "http:" the definition more closely matches expectations 
  and does not deviate with expected behavior.

  One might complain that this would require internet access or
  excessive processing.  However, with appropriate use of 
  'expired' header, the "namespace service" could very easily 
  maintain a cache of these resources off line; or a even just 
  a hash-value.  For those proceses which are *never* connected 
  to the internet; an alternative local, platform specific, 
  registry could be used.   Overall, I don't see the problem.

  As far as backward compatibility; processors with the new 
  behavior could work well on old texts.  I guess a problem 
  may exist with invalid links... but these should be "cleaned-up"
  anyway if the semantic web is to keep its integrety.  As for
  new texts working on old documents, one would have to stick
  with "pre-absolutized, unique http URIs".  

  For texts which want to switch from "http:" method to "data:"
  method; they could have their web server return the text
  following "data:" from the "http:" request during migration.

Now, is this _so_ bad?  It completely side-steps all of
the "absoultizing" or complains about violating the 
current equivance class defined for an "http:" URI.

> who _does_ benefit from the change?

  Those people who want consistency among the specifications.

The equivalence class for "http:" URIs is already defined
by resolution & retrival.  The namespace spec should not
be re-defining its own use of URIs, just as the XPath spec
should not be re-defining its own use of namespaces...

Clark

Received on Saturday, 27 May 2000 19:28:01 UTC