Re: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

[Graham Klyne <[e-mail]>]

John Larmouth wrote:
> I am sure we understand the issues and implications of comparison, and 
> for our purposes they are acceptable.  On the // issue, we have 
> oscillated on that over the production process, and our latest advice is 
> as recorded in 03 - we use only "oid:/Alerting/....." for example.   
> There *is* a use for relative OIDs (and they *are* defined in the 
> Recommendations | International Standards), but we were *not* planning 
> on allowing those in the IRI scheme, as establishing the context for the 
> relative OID/IRI is more difficult than in a controlled protocol 
> environment.

(Scheme reviewer hat OFF...)

I would say that if you use a URI form with '/'s, you cannot prevent others from 
using relative forms in ways defined generally for URIs, which may or may not be 
the same as (or isomorphic with) relative forms defined by the OID 
Recommendations.  I think it could be confusing if two different ways of doing 
relative OIDs were potentially available (even if not actually blessed by the 
specification).

The URI spec provides some guidelines for establishing the context for relative 
URIs, but these are necessarily partial for the reasons you indicate.

My comment about using '//' was because the first path-segment of your OID URI 
seemed to perform the same function as the "authority" in a URI.  I can't tell 
if it truly does.

Martin:  from my recollection of when I looked into this previously, I think 
it's OK for a URI scheme using the relative path constructs to *not* have an 
authority component, hence is not *required* to start with '//'.  My take would 
be that the leading '//' should be used if[f] the following element is an 
authority in the (loosely defined) sense of RDF 3986.

#g