On 10 Nov 2004, at 4:12 am, Tim Bray wrote:
On Nov 9, 2004, at 7:37 PM, Antone Roundy wrote:

'The value of "rel" MUST be either a name, which is non-empty and does not contain any colon (":") characters, or a URI [RFC2396bis, section 3].'

Are we going to allow relative URIs?  Or shall we change that to:

'The value of "rel" MUST be either a name, which is non-empty and does not contain any colon (":") characters, or an absolute URI [RFC2396bis, section 4.3].'

Er, Roy is using the terminology carefully, and saying URI not URI reference, but it would be better to underline this and say "No relative URIs." -Tim

I was indeed being precise and referring to an actual syntax production that does not include relative references but does include fragments (for the truly pedantic). We can't say "No relative URIs" because some people can't handle the combination of those two words without a conniption fit, and we can't say "Only absolute URIs" because that would exclude fragment identifiers. At best we could add "Note that relative references to a URI are not allowed."

On Nov 9, 2004, at 8:37 PM, Graham wrote:
Erm, I thought when a name was used it was really a relative URI to the IANA base? Meaning that the value of rel is always a URI reference and never just a name? Thus resolving that reference ("related","./related","http://iana.etc/related","http://example.com/ extension",etc), would always give you the absolute URI of the relation. That's exactly what the processing model described does. Why not say so?

Because that is what the proposal formerly said, before it was simplified
by removing that feature. There are no relative references of interest
here other than the flat namespace of the registry itself, so there is
no real value in treating it as a special case of URI reference. We get
the same effect by just concatenating the two, as Antone suggested
in a prior thread.


The value this has over XML namespaces is twofold:

  1) it encourages standardization on a small set of commonly
     agreed terms by placing those terms in a community location
     and giving them efficiency-preference in the data format; and

  2) the relation is defined as a form of content, rather than
     as a byproduct of XML name collision avoidance.

I think the IANA registry should be as simple as possible -- like
the recent changes to the header field registry and various proposals
for a URI scheme registry.  There is no need for IESG approval.

....Roy



Reply via email to