W3C home > Mailing lists > Public > xml-uri@w3.org > July 2000

Re: moving toward a decision

From: David Carlisle <david@dcarlisle.demon.co.uk>
Date: Tue, 4 Jul 2000 23:17:33 +0100 (BST)
Message-Id: <m139b0X-000OdDC@dcarlisle.demon.co.uk>
To: GK@Dial.pipex.com
CC: xml-uri@w3.org

> To provide interpretation in a wider context, one _might_ invoke RFC 2396 
> rules to determine the corresponding "namespace URI" (but this is left 
> out-of-scope).

Or alternatively (and more usefully) one might take the literal
interpretation as currently implemented in most (all?) software.
Presumably the intention of the proposed wording rather than "forbid"
is to allow either of these interpretations. (But to deprecate the
cases where the interpretations differ.)

> - Deprecation of relative URI forms might be taken to suggest that 
> satisfaction of the goal of "universal names, whose scope extends beyond 
> their containing document" [from NS rec, section 1] is not specified for 
> such forms.

Well it has always been true that relative URI references don't
provide names that satisfy that goal. "bat" (or "/dev/null") doesn't
make a good unique identifier, so I doubt anyone really objects too
much deprecating its use.

> - the definition of "identical" [from NS rec, section 1] is not applied to 
> relative URI forms (or applies only within the context of a single 
> containing document).

You can't imply from a specification of "unspecified" whether this
will or will not be applied. I would assume if the proposal is accepted
that many if not most namespace matches will just take the literal
string and compare without knowing whether the URI is relative or
absolute. If relative URI are anyway deprecated and the behaviour is
unspecified (so literal comparison is legal) why pay the runtime cost
of parsing the attribute value as a URI to see if it is relative or

Received on Tuesday, 4 July 2000 18:29:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:44 UTC