identification section -- mostly editorial

These are my comments on section 2 Identification of
  http://www.w3.org/2001/tag/2004/webarch-20040608/
as I read it; mostly editorial. A summary with
just the substantive stuff will follow in a sparate
message to www-tag.


period missing: "with any other party To achieve this goal,"

and again: "URIs that identify the same resource are called URI aliases
The section on"

I wonder if this works when printed:
 "(e.g., the more it is used in hypertext links)"
perhaps
 "(e.g., the more it is used in hypertext links, discussed in section
X.X)"
i.e. more like "(see the section on future directions for identifiers)"


I had some reservations about this in 2.2:

"To keep communication costs down, by design a URI identifies one
resource. Since the scope of a URI is global, the resource identified by
a URI does not depend on the context in which the URI appears."

but they're pretty much addressed by section 2.4. URI Overloading;
perhaps a forward reference would help; I'm not sure./


Wordy:
"Software developers should expect that it will prove useful to be able
to share a URI across applications, even if that utility is not
initially evident."

suggest:
"Software developers should expect that sharing a URI across
applications will be useful, even if that utility is not initially
evident."

redundant:

"The most straightforward way of establishing that two parties are
referring to the same resource is to compare, character-by-character,
the URIs they are using. Two URIs that are identical (character for
character)"

suggest striking the 2nd "(character for character)"

Unclear:

  Thus, the "http" URI specification licenses applications to
  conclude that authority components in two "http" URIs are equivalent

you haven't made the connection between "are equivalent"
and "identify the same resource". no suggestion handy just yet.

Hmm... overly brief?

  Agents that reach conclusions based on comparisons that are not
  licensed by relevant specifications take responsibility for
  any problems that result.

Perhaps an example would help: a false positive in a browser, along
with an explanation of why it's not that big of a deal:
the user can shift-reload or whatever.

Overly brief:

  For example, the assignment of more than one URI for a
  resource undermines the network effect.

how so? no suggestion handy yet.


Hmm... I'm not sure what point 2.4.1. Indirect Identification
makes.


er... conflict?

  Good practice: URI opacity

  Agents making use of URIs MUST NOT ...

How can a MUST NOT constraint be just good practice?
Either change the label to "Design Constraint" or
change the MUST NOT somehow.


Overly brief:

 See TAG issues abstractComponentRefs-37 and DerivedResources-43.

why see those? Maybe say a couple words about why they're relevant?


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Monday, 28 June 2004 07:43:01 UTC