RE: Comments on arch doc draft

[Copying earlier comments to www-tag]

-----Original Message-----
From: Williams, Stuart [mailto:skw@hplb.hpl.hp.com]
Sent: 25 June 2002 15:19
To: 'Ian B. Jacobs'
Cc: tag@w3.org
Subject: SKW's comments on intro-0607 (was RE: 7 June Arch Document
draft illustrates terse style).



Ian et. al,

I have read over the architecture document at [1] (last modified 2002/06/14
20:54:17) and have some comments (apologies its taken a while to write up my
annotations).

Regards

Stuart
--

General comments:
----------------
Given the billing of being terse... I expected a lot less narrative than I
found. I like the boxes that pull out statements of priniciple, and they
seem to me to work best when the are the first or nearly the first thing in
a subsection. The narrative that follows can then go on to underpin/justify
the statement if principle.

I think I really would like to see the statments of the principles of Web
Architecture listed very plainly and with little surrounding explaination in
the first pass. Fractal like passes would then reveal more of the
rationale/background in support of the articulated principles.

Introduction:
------------
Like the intro... nice and crisp. Under "2. Formats" is DOM a format?

Chapter 1 Identifiers:
----------------------

I think that we have to be very crisp on URIs and URI references. URI's are
a subset of the set of URI references (they are the one's that don't have
end in a '#' followed by an optional fragment). I think it has always been
clear that URI's identify resources, but its never been clear what sort of
thing the set of URI references that are not URIs (ie. the set of URI
references ending in '#' followed by an optional fragment) identify.

I don't have an anwser for this.

  For some a URI reference with fragment identifies part of a resource
representation; 

  For others, the old URI (Universal Resource Identifier syntax (RFC1630??))
syntax included fragments as part a URI, whereas the new URI (Uniform
Resource Identifier syntax (RFC2396)) defines both URIs and URI references -
and the distinction if any is just so many angels dancing.

Regarding RFC2396... I think you might overstate what it represents. It
defines the "Uniform Resource Identifiers (URI): Generic Syntax"... I think
that stating that it "represents a worldwide agreement on who can create
identifiers and how they take on meaning in protocols and formats." goes a
bit further than 2396 claims!

Section 1.2: URI Schemes
------------------------
In the list of 'important' URI scheme properties, item 1 states:

<quote>
An HTTP URI identifies a document -- something that can be entirely conveyed
in bits -- for which there is a mapping to a set of equivalent
representations (see scheme property 6). The mapping from HTTP URI to
document may vary over time, and the set of (equivalent) representations may
be empty. 
Editor's Note: Roy Fielding version of earlier sentence: "An HTTP URI
identifies 
</quote>

I think that the opening phrase is the subject of an unresolved TAG issue,
httpRange-14 [2]... in particular whether an HTTP URI always identifies a
document or whether an http scheme URI can be used to identify Dan's Car or
the person of Mark Baker (who asserts that http://www.markbaker.ca/
identifies him, not a document [3]). 

It is also evident that TBL is ok. about HTTP scheme URI references with
fragment-ids (can we have a term for these?) can be used to identify things
such as Dan's car eg. http://www.example.org/DansStuff#Car. What I don't
understand is where the fine line lies between what is ok to be identified
by (http scheme?) URI and what is ok to be identified by URI+fragment. If
indeed http: scheme URIs can only be used to identify documents can we be
clear about the properties of documents and non-documents (or x's and
non-x's) that enable us to make the distinction.

I think that tangled up with this we also have to be clear about whether the
terms "document" and "representation" are used synoymously. In some contexts
I think they are (being used synonymously) and in others not. Some folks
will think of dereferencing an HTTP URI as retrieving a "document" others
will think of it as retrieving a "representation" of a resource and in some
cases that (abstract) resource will be will be a document... hence the
representation will be a "repreentation of a document"... but it will not be
the document itself.

BTW... I prefer the reference to Roy's version of the sentence in the
editors note... but regardless of the wording we choose, we have to thrash
out what we actually want to say.

Item 2: not sure the reference to httpRange-14 is really necessary. The URI
scheme property is about whether the (set of) representation(s) of a
resource are static over time or not.

Item 3: the property is whether or not a deployed means of "dereferencing"
(deferencing being a so-far undefined term) exists for the scheme. Not sure
whether the reference to whenToUseget-7 is necessary - the related finding
does contain some info on dereferencing... but I'd hope for a stronger
definition of the concept elsewhere (something normative already... but I
know you and I have looked without success).

Item 4: The sub-list on URI persistence is written as two questions rather
than as axis eg. replace with:
	1) The degree to which the same URI identifies the same or different
         resources over time.
	2) The degree to which the means to dereference URI's from a given
         scheme is available over time (both long-term and short term?).

Item 6: Speaks of equivalent representations of a URI... and i think it
really is talking about equivalent representations of a URIs rather than
equivalent representations of a resource. However, may need to spell this
out more given earlier discussion of equivalent representations. I tripped
on this first time through.

Section 1.2.1 Cool URIs don't change
------------------------------------

The wording in the example is the 2nd paragraph is confusing. In particular
it reads as if a URI is assigned for the set of all versions of a particular
TR. I think this needs to be written clearly in terms of there being
concepts mapping to resource representations... ie. the concept of the most
recent version of a particular TR (eg. http://www.w3.org/TR/SVG) and the
concepts of specific versions of a particular TR (eg.
http://www.w3.org/TR/2001/REC-SVG-20010904/ or
http://www.w3.org/TR/2001/PR-SVG-20010719/).

Section 1.2.2 The economics of names.
-------------------------------------
Editorial: 2nd itemised list. Split the last bullet into two ie:

  * Can lead to battles for control as scare resources. Short,
easy-to-remember names are more valuable than random numbers

becomes:

  * Can lead to battles for control as scare resources. 
  * Short, easy-to-remember names are more valuable than random numbers

Section 1.3 Dereferencing a URI
-------------------------------

Boxed item 2. "Agents SHOULD be able to dereference URI references for
important resources." Erroneously (?) references namespacedocument-8. Also,
do we dereference URIs or URI References... again clarity (elsewhere) about
the distinction (if any) would help.

Section 1.4.1 Design Weakness...
--------------------------------
"New access protocol should provide a means to convert fragment identifiers
according to media type..."  don't understand....

Received on Friday, 28 June 2002 09:16:29 UTC