Re: 1343 messages later

Graham Klyne wrote:

> The debate seems less about *what* to say than *how much* needs to be
> said.  (I distinguish this from ignoring essential detail to paper over the
> cracks.)  Sometimes, less is more.  By *not* mandating absolutization the
> spec does not forbid this as a possibility when sufficient information is
> available.
>
> What is needed to say, I think, is that a purely textual interpretation of
> a relative URI cannot achieve the level of discrimination between different
> namespaces that is sometimes needed -- something that I think both Paul
> Abrahams [1] and David Turner et al [2] have articulated in different
> ways.  I think that [2] is more useful because it explicitly relates the
> issue of discrimination to the use-context.
>
> Whether or not this is "absolutization in principle" is, I think, moot.
>
> [1]
>
> [["The attribute's value is the namespace name identifying the
> namespace.   It must have the form of a URI reference,
> although for the purposes of this specification the
> namespace name is treated as an uninterpreted character
> string.   Other specifications and applications may choose
> to attach their own interpretations to the namespace name
> and to place additional requirements on its form or
> interpretation.  (URI references are used in this context
> because they allow such additional interpretations.)
>
> Namespace names should be chosen so as to be unique.   That
> is, the author of a namespace should choose a namespace name
> that one can assume with some confidence will not be used by
> anyone else to denote a different namespace."]]
>
> [2]
>
> [[[According to RFC 2396 a URI reference can be either a relative or an
> absolute URI. The scheme of an absolute URI identifies the URI space to
> which that URI belongs. A URI space is typically defined with a set of
> properties concerning uniqueness, normalization rules etc. as well as
> one or more default mechanisms for resolving URIs belonging to that URI
> space.
>
> Relative URIs are always defined within a context. Typical examples are
> relative references within the current document (fragment identifiers)
> and relative references between documents at the same or closely related
> level of hierarchy in the URI space. Within the same context, relative
> links remain internally consistent and can act as unique identifiers
> (within that context) without actually being expanded relative to the
> context within which they are defined.
>
> An application is responsible for knowing the context within which a
> relative link is defined. RFC 2396, section 5, provides several
> mechanisms for establishing the proper context within which relative
> URIs are defined. An application is also responsible for ensuring that
> relative identifiers are not treated as unique identifiers across
> contexts as ignorance of context can make distinct identifiers appear
> undifferentiated.]]]

Wouldn't it be possible to adopt both {1} and [2]?  They replace different
sections of text: [1] replaces the definition following the syntax in Section 2,
while [2] replaces the definition of identicality of URI references (2nd
definition, Section 1).  But as I pointed out in another message, [2] has the
problem that it does not define identicality at all, unlike the text it
replaces, and thus leaves the uniqueness test (2) of Section 5.3 undefined.

Paul Abrahams

Received on Wednesday, 14 June 2000 15:58:37 UTC