NeoXML

If the Hypermedia Affordance vowels were in an arbitrary XML namespace, this would enable the application pattern described under distributed extensibility, here.

If, however, the XML Hypermedia vowels were defined in the XML Namespace directly, and if a new mime media type, together with a new structured suffix were documented and registered, call it "NeoXML", application/nxml (+nxml), it could be used to enable the following usage pattern of XML.

The NeoXML media type would specify that there would be a virtual group of attributes on the document node of a document / message conforming to the application/nxml media type:

<foo rel="ns" href="http://www.w3.org/XML/1998/namespace" type="application/namespace+xml">
...
</foo>

Note I'm not sure how to represent attributes on the document node, since I believe the root element of the document is 'in' the document node. Hence the root element would instead look unadorned:

<foo>...
</foo>

However, the media type specification for application/nxml would say that they exist, and I believe that would be all that was necessary, if the document node could be considered to have attributes (i.e. not illegal in XML?)

This declaration (present physically or not - would be defined by the media type so would not really matter if it was not present) would imply a link to an "automatic namespace" document, which would in the case of the XML namespace resource would look like this:

<ns>
  <attribute>
    <name>href</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>src</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>type</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>rel</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>hreflang</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>method</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>tref</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>base</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>lang</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>id</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
  <attribute>
    <name>space</name>
    <uri>http://www.w3.org/XML/1998/namespace</uri>
  </attribute>
</ns>

In this way, new media types created which shared the +nxml structured suffix would be "namespace" free physically, but would benefit because a) they would have hypermedia built-in, but not forced upon them, and b) they would be namespace-free syntactically, hence simple, yet sophisticated at the same time because they would have access to namespace functionality where necessary.

Note that it would be likely that excessive traffic could be generated on the http://www.w3.org/XML/1998/namespace resource, especially if application/nxml parsers did the wrong thing and requested the resource. However, I believe this is the case with other common resources at the w3c, so similar provisions could be taken to prevent excessive load as a result of improperly implemented nxml parsers.

The consequence of the above provisions is simply that requests and responses on the web for application/nxml media type would have namespace-less attributes @href, @src, @type, @rel, @hreflang, @tref, @base, @id, @space all associated to the xml: namespace, yet without that prefix clutter. For further assignment of prefix-less namespaced elements and attributes, the modified method of adding @href="..." @rel="ns" to elements in the document should work according to the Automatic Namespaces proposal.

Note that it would not be sufficient to simply request the resource at http://www.w3.org/XML/1998/namespace and hope for the best. There is *already* an html page located at that URI. Not to worry, the web architectural style comes to our rescue. Should the request for that resource specify an Accept: preference for application/namespace+xml, the actual xml representation above would be returned instead of the html representation that you will see if you access that page with *today's* browsers.