Namespace names: modified semi-serious proposal

SINCE, from my listening, there seem to be two camps:

  a)  Those who believe that a namespace name should only
      be used for identifying, nothing more.

  b)  Those who believe that a namespace name should also
      be used for locating in addition to identifying.

AND, since two URI schema fit perfectly with those camps:

  a)  "data:" works well for the identify-only crowd; as
       the URI and the resource it identifies are co-located,
       thus, a byte-by-byte comparison of the URI works well.

  b)  "http:" works well for identify+locate crowd; as the
       URI gives instructions as to how to retrieve additional
       information regarding the schema (what ever that may be).
       In this case, a byte-by-byte comparison of the resource
       retrieved is the best way to uniquely identify a namespace
       in a manner consistent with the world's understanding of
       the http protocol.

THEREFORE,

   a)  Deprechiate all URIs other than "data:" or "http:"
      
   b)  Define the "identity" operator for two namespaces 
       as a function dependent upon the protocol.

       1.  For the "data:" protocol, the namespace "string"
           to be literally compared, immediately follows 
           the colon.
         
       2.  For the "http:" protocol, the namespace "string" 
           to be literally comparied, is the text retrieved
           from the network following typical resolution.

           If the resource cannot be retrieved then the 
           result is undefined (application specific).

   c)  For those processes which are intermittently attached
       to the Internet, the "string" for an http: namespace
       can be cached.  Ideally, a hash-value could be stored
       for the purposes of "identity".

   d)  For those processes which are not attached to the Internet
       or have limited bandwith, the "string" for an http: 
       namespace could be kept in a local registry, either 
       configured by the end-user or hard coded. 

   e)  If the "string" of an "http:" resource cannot be retrieved;
       then an error should be issued.  The application may opt to 
       allow the user to proceed by treating the URI text as 
       the "string".  

WITH COMPATIBILITY,

   f)  An old text meeting a new processor should work as expected.
       If the text uses an "http:" resource, and this resource is
       invalid, then a warning error could be issued; allowing 
       the URI to be used as the "string" for comparison.

   g)  If a new text is used on an old processor, we have no problems
       if "data:" is used exclusively; or if the "http:" resources
       are absolute and unique.
   
   h)  For a new processor where "data" treatment is desired, if
       a new text uses "data:" and an older text uses "http:", 
       then the http resource should return the same string as
       found after the colon in the data URI.

   i)  For an old processor, if a new text uses "data:" and an
       old text uses "http:" , then the result will be invalid.
       However, it should be clear that a match would fail, and
       fail so hard that the error should be detectable...


Thoughts?  This solves both camps needs and provides a migration path.

Best,

Clark

Received on Saturday, 27 May 2000 20:40:15 UTC