Comments on archdoc section 1.1

Comments on 
section 1.1. I'll comments on the sections in turn.

# 1.1 Use of terms URI and URI reference

# "RFC 2396 divides the world of resource identifiers into:"

I have a lot of problems with this sentence:

Firstly, RFC 2396 makes no pretense of covering 'the world' of
resource identifiers. There are as many kinds of resource
identifiers as you can imagine. RFC 2396 merely defines *a* world
of resource identifiers; in particular, a world of 'uniform'
(uniformly interpretable) ones.

I think the binary partition between 'absolute' and 'URI reference'
isn't right. The key to RFC 2396 is to look at the BNF terms
actually defined. There are absolute URIs (absoluteURI)
and relative URIs (relativeURI) and URI references

Further, RFC 2396 doesn't really "divide" its world this way,
it merely defines some terms. Perhaps the TAG wishes to
define some other terms, too, but there's no value in taking
the terms defined in RFC 2396 and trying to redefine them
differently. Perhaps there is a use for the term
"absolute URI reference" (a URI reference consisting of
an absolute URI and optionally a fragment identifier)
and the term "relative URI reference" (likewise),
but then, you would still wind up with a different
'division' (e.g., 2 ways between URIs and URI references,
and, within those, 4 ways between those that are absolute
and those that are relative.)

# An absolute URI is a string of characters starting with
# a URI scheme.

Surely this isn't meant to be definitional -- perhaps just
evocative? An informal attribution? An absolute URI is
a string of characters that matches the syntactic definition
of "absoluteURI", which includes the restrictions in RFC 2396
and also, by reference, any restrictions imposed by the
definition of the scheme.

# A relative URI reference is a syntactic abbreviation for an
# absolute URI.

An 'abbreviation' is a shorthand form which stands alone
to represent the thing it is an abbreviation for. But
of course the relationship between a relative URI
and the absolute URI derived from it depends on the
base. So perhaps some other phrase than 'abbreviation for'
would be better.

# What a relative URI reference identifies depends on
# the context where it is used.

It depends in a very particular way, which isn't stated.
The 'context' is only used to determine the base. And
the identification is indirect: the relative URI is used
to determine an absolute URI.

# Absolute URIs or relative URI references, followed optionally
# by "# and a fragment identifier.

This category doesn't make any sense in any of the divisions.

# In practice, people use both absolute URIs and absolute URI
# references with fragment identifiers to identify Web resources.

Actually, no. In practice, people use URIs to (uniformly)
identify resources, and URI references with fragment identifiers
to identify fragments of resources. The usage is pretty
consistent. ''
identifies the resource of the architectural document, and
identifies Chapter 1 of it. To confuse resource fragments
with resources would be a serious mistake.

# Therefore, in this document, the TAG defines the terms URI
# and URI reference as follows:

# URI 
# In RFC 2396 terms, an absolute URI followed optionally
# by "#" and a fragment identifier. 
# URI Reference 
# Same as the RFC 2396 definition. 

# The TAG intends to request a revision to RFC 2396 to
# adopt this usage.

The term "URI" is used within RFC 2396
informally (there is no BNF terminal labeled 'URI')
to refer to any of the different kinds of terms defined:
URI-reference, absoluteURI, relativeURI. So it might
be that the TAG is requesting that there be a more
formal definition, and that the term 'URI' be assigned
to 'URI-reference based on an absoluteURI'. Perhaps
the idea is to add a BNF item:

   URI    = absoluteURI [ "#" fragment ]

but I think this term could be covered more accurately
by "absolute URI reference".

The intent for any revisions of RFC 2396 would be to
bring it to full "Internet Standard" status in IETF,
following the guidelines of RFC 2026.

I don't think this proposed redefinition will help.

Note that the consistent usage in W3C specifications to date
has been to refer not to any of the RFC 2396 syntactic
constructs, but instead to the category of IRIs, which
have related but different syntactic rules. I would think
that it might be useful -- in this document -- to at least
note the different usage, and perhaps to resolve it.


That's all the comments for now; I'll review the next
subsections soon.


Received on Wednesday, 14 August 2002 10:54:01 UTC