Using URNs for namespace URIs in AstroGrid schemata

It annoys me when URLs in the HTTP scheme are used as URIs for XML namespaces. "http://" on the front of a URI means a URL for a resource reachable via HTTP transfer; to use it as a namespace is to lie, since the schema can't always be downloaded from its namespace URI; and anyway one has to write separate URLs in schemaLocation attributes to make the XML work. It's an example of the ontological relationship "looks a bit like but is different really and we know what we mean so that's good enough".

Uniform Resource Names (RFC2141) are a formal way of making a location-independent name, and we should use them. That's the syntax with lots of colons and no slashes, as in

  urn:astrogrid:schema:cea:CEAService:v0.2

As in all URIs, the bit before the first colon is the scheme name, always urn. The bit between the first and second colons is the "namespace ID (NID)", analogous to the authority part in a URL. The part following the second colon is the "namespace-specific string (NSS)" and any colons inside it are part of the name.

I suggest that we always use astrogrid for our NID in URNs. I originally expected to use astrogrid.org, but RFC2141 doesn't allow punctuation other than a hyphen in the NID. Case doesn't matter in the NID, so write AstroGrid if you like. I'll write astrogrid in lower case because I think it looks neater in this usage.

I suggest that we always put schema: (singular and lower case) as the start of the NSS when naming XML schemata and WSDL contracts. The NSS is hierarchical and we're likely to use other top-level categories of URN. I suggest that we use colons to separate levels of hierarchy in the NSS (slashes are not allowed by RFC2141).

URNs are formal and need to be controlled. Therefore, I suggest that we register all new URNs in a file in the new "contracts" component.

If you create your own URN, please remember that the NSS in a URNs is case-sensitive but the NID is not! The set of allowed characters in the NSS is quite restricted, so check with the RFC.

-- GuyRixon - 11 Feb 2005 (multiply updated this day; "and the demands will all be changed, so stay awake!")