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.
Forwarded message 1
***** 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.