Hierarchical Profile and the URI

["Hal Lockhart" <hal.lockhart@oracle.com>]

In addition to previously discussed issues, I would like to fix the sections in the hierarchical profile on using URIs.

In section 2.2 the profile says:

----
The identity of a node in a hierarchical resource that is not represented as an XML document instance SHALL be represented as a URI that conforms to [RFC2396]. Such URIs are of the following form.
	<scheme> ":" <authority> "/" <pathname> 
----

This is not true and it is not what RFC 2396 says. In section 3, it says:

---
The URI syntax is dependent upon the scheme.  In general, absolute
   URI are written as follows:

      <scheme>:<scheme-specific-part>

   An absolute URI contains the name of the scheme being used (<scheme>)
   followed by a colon (":") and then a string (the <scheme-specific-
   part>) whose interpretation depends on the scheme.

   The URI syntax does not require that the scheme-specific-part have
   any general structure or set of semantics which is common among all
   URI.  However, a subset of URI do share a common syntax for
   representing hierarchical relationships within the namespace.  This
   "generic URI" syntax consists of a sequence of four main components:

      <scheme>://<authority><path>?<query>

   each of which, except <scheme>, may be absent from a particular URI.
   For example, some URI schemes do not allow an <authority> component,
   and others do not use a <query> component.
----

Some URI schemes use a hierarchical path component with segments separated by "/" and others do not. This is not mere nitpicking as the XML Schema AnyURI type is defined as containing "a URI as defined by RFC 2396. This means a valid type checked element of type AnyURI can contain something like email:john@example.com or http://www.example.com/main/index.html.

It seems to me that we should recommend as a matter of best practice that policies first check the scheme name using the uri-starts-with function before using any regex functions to pick the hierarchical portion apart.

This brings us the question of what type of URI to allow or permit to be used to represent a hierarchical resource on the non-XML type. Obviously since we decided to allow any data type, we can no longer require that a URI be used at all. However, I suggest we follow the existing profile and say that if a URI is used, then if the resource already is named using a registered scheme OF THE HIERARCHICAL TYPE, then that should be used, otherwise a "file" scheme URI should be constructed as described in the current (2.0) profile.

Hal