Distributed extensibility / automatic namespaces

Liam Quin has defined a simple XML media type which enables a way to gain the benefits of namespaces (identifying the specification for an element in a composite XML document, preventing name collisions) which allows the elimination of namespace-prefixes in XML documents. Please read the paper here: http://www.balisage.net/Proceedings/vol3/print/Quin01/BalisageVol3-Quin01.html

The described mechanism, used in concert with the XML hypermedia vowels, could work to associate the href,src,type,rel,method,hreflang and tref vowels _without_ namespace prefixes in instance documents to the namespace in which they were defined - which could be anything, including "http://example.com/namespaces", of course.

The mechanism which Liam suggests to encode the link to the automatic namespace document lacks (explicit) support for content negotiation. The original proposal suggests the addition of @xml:ns to the xml: namespace as the mechanism for encoding the link to an automatic namespace file. However, the general case on the web is that there may be more than one representation of that (namespace) (or any) resource available, and thus the client would specifically need to express/negotiate a preference for a particular representation media type. "xml:ns" would presumably 'bundle' an implied preference for application/namespaces+xml. So, the proposal to which this example belongs is to add the hypermedia affordance vowels to the xml: namespace, so as to make it possible to use @xml:type to make explicit the fact that the negotiation should proceed with a preference for application/namespaces+xml. So in this case, instead of using

  <foo xml:ns="http://example.com/namespaces">
   ...
  </foo>

one would use

  <foo xml:href="http://example.com/namespaces" xml:type="application/namespaces+xml" xml:rel="ns">
   ...
  </foo>

It should be noted that there is nothing about the automatic namespace proposal which requires the addition of the hypermedia affordance vowels to the XML namespace per se. What it does require is the addition of at least a link attribute to the xml: namespace ("@xml:ns").

In fact, the automatic namespace proposal would enable "automatic namespace" hypermedia vowels regardless of what namespace they were associated with. This is not necessarily a positive fact, however, since an enormous part of the value of xml: namespace-based standard hypermedia vowels is that they are standard, and reliable in their syntax. i.e. the namespace prefix cannot be reassigned.

The following discussion illustrates an application of the automatic namespaces mechanism to hypermedia affordance vowels associated with the "http://example.com/namespaces/hypermedia" namespace, using the prefix "h".

In a "normal" XML+Namespaces Scotch Markup Language (made up for the sake of this example) instance document, content might appear like this:

<sml:SingleMalts xmlns:sml="http://scotch.org/ScotchML" 
  xmlns:h="http://example.com/namespaces/hypermedia">
  <sml:whisky>
    <sml:name>Glenfarclas</sml:name>
    <sml:history>
      <sml:p>Glenfarclas is the brand name of one of the finest Speyside malts available.  
        <sml:a h:href="http://en.wikipedia.org/wiki/Glenfarclas_Single_Malt">
          See wikipedia for more information
        </sml:a>
      </sml:p>
    </sml:history>
  <sml:whisky>
</sml:SingleMalts>

(prefixes added everywhere to visually complicate things, but often seen like this, in fact).

whereas in an XML hypermedia vowels+automatic namespaces version of the same file, one might see:

<SingleMalts h:href="http://scotch.org/ScotchML" h:rel="ns" h:type="application/namespaces+xml"
  xmlns:h="http://example.com/namespaces/hypermedia">
  <whisky>
    <name>Glenfarclas</name>
    <history>
      <p>Glenfarclas is the brand name of one of the finest Speyside malts available.  
        <a href="http://en.wikipedia.org/wiki/Glenfarclas_Single_Malt">
         See wikipedia for more information
        </a>
      </p>
    </history>
  <whisky>
</SingleMalts>

the application/namespaces+xml representation at http://scotch.org/ScotchML would contain:

  <ns>
    <element>
      <name>SingleMalts</name>
      <uri>http://scotch.org/ScotchML</uri>
    </element>
    <attribute>
      <name>href</name>
      <uri>http://example.com/namespaces/hypermedia</uri>
    </attribute>
    <attribute>
      <name>src</name>
      <uri>http://example.com/namespaces/hypermedia</uri>
    </attribute>
    <attribute>
      <name>type</name>
      <uri>http://example.com/namespaces/hypermedia</uri>
    </attribute>
    <attribute>
      <name>rel</name>
      <uri>http://example.com/namespaces/hypermedia</uri>
    </attribute>
    <attribute>
      <name>hreflang</name>
      <uri>http://example.com/namespaces/hypermedia</uri>
    </attribute>
    <attribute>
      <name>method</name>
      <uri>http://example.com/namespaces/hypermedia</uri>
    </attribute>
    <attribute>
      <name>tref</name>
      <uri>http://example.com/namespaces/hypermedia</uri>
    </attribute>
  </ns>

Of course, the attributes in the http://example.com/namespaces/hypermedia namespace could be included via Liam's suggested use of an @src link, but are presented directly here for the sake of clarity of the example.

In fact, because of the recursive definition of the mapping of h:href, h:src, h:type, :rel, h:hreflang, h:tref to the "non-namespaced" attributes of the same name in the instance document, it might be possible simply to refer to the automatic namespace resource with a link constructed like this:

which relies partly on the "recognizability" of the hypermedia vowels local names. In effect, because of the @type (+/- @rel) value (application/namespaces+xml), the SingleMalts@href can be recognized by a parser familiar with the application/namespaces+xml media type as meaning "@h:href", and similarly @type for "@h:type" and @rel for "@h:rel".

The above is struck out because I don't believe it is valid. This would require the association of the hypermedia attributes to a media type, which is not the case here, we're simply dealing with a plain old XML file in conjunction with a parser enabled for application/namespaces+xml. This example does not assume the presence of the hypermedia vowels in the xml: namespace - that idea is left to the NeoXML use case.

Note that there is nothing (in this example use case) requiring the inclusion of href,src,rel,type,hreflang,method and tref in the actual XML namespace, hence the use of "h" and http://example.com/namespaces/hypermedia in this discussion. Any namespace with a definition of these values would do. However, in order to enable the layered use case of NeoXML (or any new media type based on XML), it would be necessary (I think), or at least highly elegant, to include these attributes in the XML namespace definition resource at http://www.w3.org/XML/1998/namespace.

Also, and as noted by Liam's original proposal, there is nothing preventing the user from using namespaces, prefixes and all, in an xml document constructed according to the automatic namespaces proposal, with or without the hypermedia vowels per the above discussion.