Architecture document comments

Reviewing:
   http://www.w3.org/TR/2003/WD-webarch-20030326/

I see this taking some substantial shape and content, and look forward to 
seeing it become a respected point of reference.

Here are a few small points I noticed...

...

Section 3, para 1:

I felt the reference to "semantic rules of URIs" could be confusing.  Maybe 
here it would be sufficient to say simply: "... agreement to follow the 
rules of URIs ..."

...

Section 3, para 2:

I think it's great that this document attempts a description of what 
constitutes a "resource".  But I feel the phrase "all those things that 
populate the web" could be read as being in conflict with the examples that 
follow, and also the text later in section 3.3.  My concern hinges around 
the word "populate, which can be taken to suggest something that is 
actually part of the web, to the exclusion things that are described by the 
web.

My suggestion:  "... all those things that are represented on the Web: ..."

...

Section 3.1, para 3:

typo in OWL10 reference?  (double [[ and ]])

...

Section 3.1, para 5 (following Good practice note):

I felt that this paragraph (...ensuring sufficient difference...) would 
also justify a "Good practice" point.

...

Section 3.3, para 1:

I was rather uncomfortable with the introductory phrase "In some URI 
schemes...", in that it sets an expectation that fragment identifiers have 
a direct dependency on the URI scheme used.  Later text makes it clearer 
that any such dependency is indirect.  (I think I can imagine some software 
scenarios in which "mailto:nobody@example.org#abc" *does* have a practical 
meaning, given that the resource identified as "mailto:nobody@example.org" 
is a mailbox, the default "view" of which is initiate composition of a 
message to be sent to it.)

So I suggest:  "It may be meaningful for a URI to end with a fragment 
identifier ...".

Also, in para 2, I suggest:

"Note that while this composition is syntactically fully general, it is 
less likely to be useful with some URI schemes.  The URI 
mailto:nobody@example.org#abc does not have a well-understood meaning in 
practice."

...

Section 3.3, para 1:

This paragraph seems to focus on the idea that a fragment is part of the 
thing identified by the fragment-free URI.  Three paragraphs later, it is 
clearer that being "part of" is not a requirement.  I am thinking about a 
possible form of words that makes this clearer.  Saying "view" is better, 
but it still seems to suggest a physical sameness of resource and 
fragment.  "projection"?

E.g.
"... to yield an identifier for a projection of (e.g. a part of, or a view 
of) a resource."

...

Section 3.4, paras 1,2:

There seems to be a conflict between the first two paragraphs.  The first 
seems to say that dereferencing is based on the URI ("beginning with ... 
the scheme of the URI");  the second says that the dereference mechanism is 
dependent on the context.  I'm not sure what the actual intent of this text 
is meant to be, so I can't really offer an alternative.

In thinking about this, it seems to me that there are some legitimate 
scenarios that are not clarified by this; e.g.


(1) using HTTP-over-IPv4 vs HTTP-over-IPv6.  The choice here is determined 
by both the context (what IP versions the client supports), indirectly the 
URI (what IP versions supported by the origin server or availoable proxies) 
and the URI (does the URI contain an IPv6 or IPv4 literal).


(2) I have heard it suggested that a new hypertext access protocol might be 
deployed, and used for dereferencing http: URIs.  This is implicit in the 
argument that identifiers rooted in http: URI space are OK to use as more 
general identifiers.  E.g. see [1].

[1] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0118.html
and replies:
     http://lists.w3.org/Archives/Public/www-tag/2002Feb/0179.html
     http://lists.w3.org/Archives/Public/www-tag/2002Feb/0180.html
     http://lists.w3.org/Archives/Public/www-tag/2002Feb/0182.html

If an when a bigger, better hypertext protocol is deployed, and if it is 
used to dereference http: URIs, to what extent is the context and to what 
extent is the URI determining the dereferencing mechanism?


(3) Within a given environment (e.g. cellphones?), some different protocol 
can be used to dereference http: URIs (which may or may not eventually 
invoke a "native" http: transaction.


I suspect the best that can be said here is that it is a combination of the 
URI and context of use that determines the dereferencing mechanism employed.

...

Section 3.4.1:

The relationship between this section and 3.4 is not entirely clear.  I am 
guessing that retrieving a representation is presented as a particular kind 
of dereferencing?

...

Section 3.4.1, Principle:

This principle seems to be so important, so fundamental, that it seems 
all-at-sea buried this deep in a relatively arcane discussion.  I think it 
belongs right up at the start of section 3, as part of the lead-in to 
identification and resources.

...

Section 3.4.3:

I liked this.

...

Section 3.4.4:

I did wonder in passing if this section was about identification or 
interaction.

...

Section 3.4.4, para 7:

In:
[[
Persistence is always a matter of policy and commitment on the part of 
authorities assigning URIs rather than a constraint imposed by 
technological means.
]]

the reference to "assigning URIs" seemed open to misinterpretation (e.g. as 
an ISP handing out blocks of URI space for its customers' use?).  Given the 
terminology introduced earlier, maybe say:

[[
Persistence is always a matter of policy and commitment on the part of 
authorities servicing URIs rather than a constraint imposed by 
technological means.
]]

...

Section 4.3.3:

The question noted here seems to be answered in section 3.3.

...

Section 4.4, para 2:

Typo?  Missing comma (,) between "concepts" and "content"?

...

Section 5.2, Good practice note:

Typo:  "uniform address spac"

...

Section 8:

It's not clear to me what it means for a reference to be normative vs 
non-normative in this document.

...

--end--



-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Tuesday, 8 April 2003 10:46:41 UTC