Raising a few issues in fielding-uri-rfc2396-0x

[My first appearance on this list I believe, flame away cheerfully if I 
transgress any protocols, I learn fast.]

1. The document inconsistently uses both URI and URIs as the plural of 
URI, sometimes within a sentence or two of each other.  While I 
appreciate that there is a sound English-orthography argument for URI 
being the plural form, I have never seen this used aside from here and 
in Roy's notes.  A couple of years I once spent working on the Oxford 
English Dictionary project have convinced me that as regards usage, you 
might as well go with the flow, so I'd counsel going with URIs, but 
failing that, at least having internal consistency.

============================

2. 1.2 - the spec says it deprecates the terms URL and URN and I'm not 
sure it really does.  What it's really deprecating is the notion of a 
clean useful separation between locators and names.  I've never seen 
"URN" used in this sense anyhow, in fact I've never seen it used aside 
from a reference to what the URN RFC defines, which is hard to argue 
against.  If you want to deprecate the term URL that's at least 
consistent, although once again I have some nervousness about trying, in 
the Academie Francaise style, to stop people from using words they want 
to use.  Potential reword of the paragraph:

'An individual scheme does not need to classified as being just one of 
"name" and "locator".  Instances of URIs from any given scheme may have 
the characteristics of names or locators or both, often depending on the 
persistence and care in the assignment of of identifiers by the naming 
authority, rather than any quality of the scheme.  For this reason, this 
specification deprecates the use of the term URN for anything but URIs 
in the "urn" scheme as described in RFC 2141.  This specification also 
deprecates the term "URL".'

================================

3. 1.2, fourth para; the phrase "just like any identifier" is superfluous.

============================================

4. Section 3

This section is awfully short of examples.  I would think the usefulness 
would be improved by including at least one example for each of 3.1, 
3.2.1, 3.2.2, 3.3, and 3.4.  If others agree, I would volunteer to cook 
up the examples.

===========================

5. Section 4.

"URI-reference" is hyphenated the first time it appears and I don't see 
why.  Such hyphenation normally only appears in English when multi-word 
particles are used adjectivally, e.g. "URI-reference absolutization 
rules" would be expected.

==================================

6. Section 4.

I think the first paragraph is kind of convoluted.  Let me try to boil 
it down a bit; if I've misunderstood what it's trying to say that in 
itself would be a useful diagnostic I think.

'The term "URI Reference" describes a commonly-used syntax for resource 
identifiers, which may be absolute or relative and may include 
additional information in the form of a fragment identifier.  Each URI 
Reference may be mapped to a URI by converting it (if relative) to its 
absolute form and removing the fragment identifier.  While this 
specification's discussion of syntax and semantics is mostly concerned 
with the absolute form of URIs, it is recognized that most usages of 
URIs take the form of references.'

=================================

7. Section 4.

As to "." and "..", I agree with TimBL that it is violently inconsistent 
to restrict the special meaning of these syntaxes to the relative form 
of URIs.  If I am given the URI http://example.com/a/./b/../c I will 
always, 100% of the time, regard that as http://example.com/a/c. I have 
just verified that the first two randomly-picked web browsers I picked 
in fact do this.  So the assertion that this only applies to the 
relative form is, I assert, simply wrong and should be removed.

==============================

8. Section 5.

Same as comment #4 above; examples would improve this, and if others 
agree, I'll cook some up.

==================================

Received on Friday, 21 February 2003 16:44:49 UTC