Re: [Tim Bray] Review of webarch-20040816

/ Norman Walsh <Norman.Walsh@Sun.COM> was heard to say:
| 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.
| From: Tim Bray <tbray@textuality.com>
| Subject: Review of webarch-20040816
| To: www-tag@w3.org, "w3. org" <www-tag@w3.org>
| Date: Wed, 01 Sep 2004 07:45:15 -0700
| X-Sent: 3 weeks, 2 days, 2 hours, 47 minutes, 31 seconds ago
| Message-id: <8934D700-FC25-11D8-B7E2-000A95A51C9E@textuality.com>
|
| ***** 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.

I believe I've improved that text.

| **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".

"URI owner" has the advantage that it ties back to the section on
URI ownership.

| **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."

As I said, the whole "information resource" notion is in flux.

| **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.

Ok.

| 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.

Better?

<p>Assuming that a representation has been successfully retrieved, the
expressive power of the representation’s format will affect how
precisely the representation provider communicates resource state. If
the representation communicates the state of the resource
inaccurately, this inaccuracy or ambiguity may lead to
<a href="#URI-collision">URI collision</a>. Efforts like the Semantic Web
are seeking to provide a framework for accurately communicating the
semantics of a resource in a machine readable way. Machine readable
semantics may alleviate some of the ambiguity associated with natural
language descriptions of resources.</p>

| **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.

Actually, I don't think you can do any operation with a secondary
resource. Is this better?

<li>One cannot carry out an HTTP operation
using a URI that identifies a secondary resource. (The semantics of
HTTP GET provide for client-side interpretation of the secondary
resource, but those semantics do not apply to POST, PUT, or any
of the other HTTP operations)</li> 

| **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.

Works for me. Thanks!

|   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.

I'm not sure what to do here. But I'm also not sure you're asking for
a material change. Are you?

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

Ok.

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

I'm not sure off the top of my head.

| **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.

Yep.

| 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.

Ok.

| **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.

I expect that removing it would raise objections too. Besides, schemas
can be annotated. If you don't object to OWL as a namespace document,
do you object to a schema language that contains the same OWL
assertions?

| **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.
| ----------

Suggestions?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.