Relative URIs were never intended as a namespace name.

Here is an attempted demonstration for the 
stated assertion:

  Relative URIs were never intended as a namespace name.

...

  Exhibit A:   Section 2 of the specification
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    "[Definition:] The attribute's value, a URI reference, is the 
     namespace name identifying the namespace. The namespace name, 
     to serve its intended purpose, should have the characteristics 
     of uniqueness and persistence. It is not a goal that it be 
     directly usable for retrieval of a schema (if any exists). An 
     example of a syntax that is designed with these goals in mind
     is that for Uniform Resource Names [RFC2141]. However, it should 
     be noted that ordinary URLs can be managed in such a way as to 
     achieve these same goals."

    First, it says that the attribute's value *is* 
    the namespace name identifying the namespace.  
   
    Then, it says that the namespace name should
    be unique and persistent.

    Therefore, the attribute's value should be 
    unique and persistent.

    Unfortunately, a relative URI, as an attribute
    value, is not unique; it must be absolutized
    for uniqueness.  And this process is not mentioned
    in the definition.

    Further, it clearly states that using the "namespace name"
    as a reference for resource retrival is *not a goal*
    And it further points out that "ordinary URLs *can* be
    managed in such a way as to achieve these same goals".
    This last sentance seems to drive home the point that 
    not all URIs make acceptable namespace names.

    Lastly, the spec calls the construction a "namespace name"
    *not* a "URI reference".  

  Exhibit B:  Section 1 of the specification
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

  "[Definition:] URI references which identify namespaces are
   considered identical when they are exactly the same
   character-for-character.     
   Note that URI references which are not identical in this 
   sense may in act be functionally equivalent. Examples 
   include URI references which differ only in case, or 
   which are in external entities which have different 
   effective base URIs."

  First, it is clear that describing the notion of "identity" 
  is the primary goal of any naming system.  Here it is
  clear; a URI reference, when used to identify namespaces,
  are identical when they are the same character-for-character.

  It is obvious that relative URIs cannot therefore be used
  for the "identity" operation on namespaces in a meaningful
  way.  And since the entire goal of the spec is to define
  "identity"; it should be clear that the spec never intended
  for relative URIs to be used.

  One might construe the second part of the above paragraph
  to be "vague enough" to allow relative URIs.  However,
  this second part is discussing URIs *in-general* ... it
  does not qualify the URIs being discussed to those which
  identify namespaces.  

  Assume that the second part of the definition was talking
  about non-identical URIs used as a namespace names.  This
  leads to a contradiction.  The whole purpose of a namespace
  specification is to define the "identity" operator.  Thus,
  functional equivalent in the namespace context means 
  "equivalent under the identity operator".  In this case, 
  a namespace name cannot be both "not identcal" and
  "functionally equivalent" at the same time.  Thus, this
  second part was clearly discussing URIs used for other
  non-namespace purposes... such as pointing to a resource
  such as a schema.

  Exhibit C:  Section 5.3 of the namespace specification
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  "In XML documents conforming to this specification, no 
   tag may contain two attributes which 1. have identical 
   names, or 2. have qualified names with the same local 
   part and with prefixes which have been bound to namespace 
   names that are identical."

  If relative namespaces are allowed; and this clause 
  becomes inconsistent.  Given the care the specification
  authors gave to their document; I doubt that this would
  have made it through the editing process as-is if 
  relative URIs or an absolutizing mechanism were viewed
  in the realm of possibilities.

  Exhibit D:  Examples in the namespace specification
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   Not one example was given that used relative URIs


  Exhibit E:  Interaction with XSLT/XPath
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   
   Not one of these specs talk about relative URIs or
   how name matching would work; leaving the reader to 
   assume that the "identity" operator defined in the
   namespace specification is the only tangeable method
   for acertaining equivalence of named nodes.

  Exhibit F:  Discussion on XML-DEV
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   I do not recall one post during the time that this
   specifiction was under discussion before recommendtation
   status where relative URIs were considered.  If there
   was a post regarding relative URI interpretation, it
   would have raised all types of questions before it was
   moved to a recommendation.  In short, full URIs were
   sold... not relative URIs.  Vague or not, this is the
   context in which the specification was approved.

  Exhibit G:  Use Cases
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
   So far, on this list, the primary use-cases for relative
   URIs seem to be based on some notion of resource retrival.
   In this context, relative URIs are indeed very useful.

   However, the specification specifically states that 
   retrival of a schema or other contextual document by
   the namespace was *not a goal*  ; thus the primary 
   use case presented does not help solve the need that
   namespace spec is fulfilling.   
 
   I assume relative URIs will be very helpful in the Schema
   specification, where the retrival of a schema document is
   the primary use of the URI.
   
  Exibit H:  Current Discussion
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
   That there is suprise about relative URI usage speaks
   for itself.   It was not expected.  

...

While one of these may be proof by themselves; taken together,
I feel that they produce a solid picture that relative 
URIs were not intended by the specification authors nor its 
approvers as namespace names.   Therefore, I see this assertion 
as proven.  I feel that calling the spec "vague" does us 
a dis-service.

If relative URIs are to be used as part of a namespace
specification, I feel it should be a new (or revised) 
recommendation.  The current spec is clear enough.

Best,

Clark Evans



P.S.  My opinions may not be the opinions of my employer.

Received on Wednesday, 17 May 2000 11:50:48 UTC