[Tim Bray] Review of webarch-20040816

I'm forwarding this to the comments list so that it gets integrated
into our tracking system. I'm breaking Tim's message into two parts,
one for substantive issues one for editorial issues.

attached mail follows:

***** First, issues that I think are really material, i.e. that I would 
be inclined to raise a formal issue against webarch if they are not 
addressed.

**2.2

The sentence beginning "While other communications may suggest..." 
baffles me.  What other communications?  This needs an example, I have 
no idea what we're talking about.

**2.3.1

1st Good practice.

Is this good practice really limited to "URI owners?"  Other plausible 
targets would be "Creators of URIs" or "resource owners".

**3.1

It should be stated somewhere in here that "There is no way to tell 
whether any given URI identifies an information resource without 
attempting to dereference it."

**3.2.1

1st para.  s/are involved/govern the process/.  This this the same 
issue I keep raising on successive drafts; webarch must not leave room 
for pedants to claim that governing specifications are involved at 
run-time.

last para: This paragraph is totally indecipherable to me.  The first 
sentence is true, I guess, although I don't see what it adds to 
webarch.  The sentence about natural language, I don't get it, why is 
it in the same paragraph?  What's its goal? Maybe it should be in a 
different section, maybe it needs an example.  Maybe it's making some 
point with architectural import that I'm just not getting.  In need of 
major surgery, I'm not suggesting changes because I just don't get it.

**3.3.1

#2 in list: It's not just POST right, it's PUT & DELETE & anything but 
GET?  Hmm, don't have 2616 handy.  In any case, please be clear & 
complete as to which verbs apply.

**3.6

para beginning "A corollary to..."

No.  This isn't a corollary at all.  I'd suggest a rewrite of this 
little sequence:

------
Just because a representations are available does not mean that it's 
always desirable to retrieve them.  In fact, in some cases the opposite 
is true.  Dereferencing a URI has a (potentially significant) cost in 
computing and bandwidth resources, may have security implications, and 
may impose significant latency on the dereferencing application.  
Dereferencing URIs should be avoided except when necessary.

  Principle: Reference does not imply dereference

  An application developer or specification author SHOULD NOT
  require networked retrieval of representations as a consequence
  of recognizing or processing a URI.
------------------------------------

**3.6.2

The first paragraph here is weaker than in previous drafts, why?  The 
sentence about "In exceptional circumstances..." is BS, once a URI is 
out in the wild it's always OK to pass it along.  I think we have to 
recognize that the action of *publishing* a URI is actually crucial 
here, once published it's always OK to republish.  But if I email you a 
pointer to an unpublished page, that's not the same as publishing it.

**4.4

1st good practice:
s/portions of representation data/secondary resources/

**4.4.1

Sigh, has this section been punctured below the waterline by late revs 
to 2396bis?

**4.5.3

1st para.  Last sentence is wrong.  The URI isn't the prefix.  I tried 
a couple of rewrites but couldn't come up with anything good... suggest 
losing it.

para beginning "s/of any type/of many types/"... it's not a condition 
of being a global attribute that it necessarily apply to *all* 
elements; I'm sure counter-examples could be dug up.

**4.5.4

2nd-last para.  As long as drafts keep claiming that [XMLSchema] is an 
appropriate namespace document, I will keep objecting.  I think it is 
BAD PRACTICE to provide a syntactic schema (any kind, DTDs or RNG too) 
as a namespace document... a schema generally provides neither 
human-readable documentation nor does it enable software to do much of 
any usefulness, thus failing both the criteria defined in this section.

**4.6

1st sentence.  Earth to webarch... Huh?  Data formats enable new 
classes of applications, and the claim that this is necessarily related 
to #fragid semantics is ridiculous.  In fact, the most common reason 
for defining a new data format is to enable new application classes.  
Examples of data formats that imply new application classes: HTML, SVG, 
RSS, etc etc etc.