RE: 13 Aug Arch Doc available for review

Hello Ian,

Thank you for this new draft. I've made a number of comments and have more
yet to transcribe... I've followed Tim Bray's notion of giving each comment
an identifier so that you/others can make a short-hand reference the
comment. The day is getting on here...

best regards

Stuart
--

General
-------

Document style/structure
------------------------

[skw-2002-08-14-01]

Some weeks ago the TAG members at least applauded a direction for this
document that tended toward a terse style of presentation, with the removal
(or deferral) of so-called 'fluff' to later parts of the document or indeed
to other documents. If you like a distinction between terse 'reference'
material and more discursive 'tutorial', 'explainatory' or 'informative'
material. I think that the crispness that we found appealing has to some
extent been lost. I have some suggestions about addressing this...

Firstly, we have not been clear about the intended audience of the document.
I guess the answer is a broad ranging audience, which is why there is a
tangle of reference and tutorial material. My preference would be that we
pulled the reference material to the front of the document with little/none
of the narrative that elaborates on a terse/crisp set of staments of
principle. Each of these references further into the document to where the
principle is restated (for those taking the linear path) and set incontext
alongside the relavant supporting material that justifies and elaborates.

The other temptation would be to put a reference at the back.... as a
recap/summary... but I would prefer it at the front as a reminder for the
very savvy reader and a navigation aid for the enquiring reader that needs
the expansive material.

If we were to go that way, I'd also add a small piece of advice to the
reader setting expectation on how the document is structured.

--

[skw-2002-08-14-02]

There seems to be the synonymous use of the words "designate", "identify",
"reference" and "represent" (the latter just once in 1.5.2.1 "...TELNET URIs
represent telnet services...". The difficulty is that the use of different
words synonymously ins some contexts leads the read to imagine subtle
differences that are probably not intended. I would have included the word
'denote' in this list to... but I didn't come across any occurences :-).

--

URI and URI References
----------------------

[skw-2002-08-14-02]

I am very wary of the attempt to redefine the terms URI at the end of
section 1.1. I think the terms URI and URI reference have been a source of
problems in the past and will likely be a source of problems to come. But
IMO, the definition of TAG-URI = AbsoluteRFC2396URI+OptionalFragment will
make this document almost unreadable to anyone with a deeply infixed notion
of URI based on current conventional usage. If the thing that we want to
talk about is an absolute URI with optional fragment then that is the term
we should use. If it is too cumbersome to use repeatedly when we want to be
that specific then we might reasonably, and with some care, invent a term
(if there isn't one readily available elsewhere) for the set of URI
admissable under that construction. There are infact several subsets of the
URIRef space that we might want distinguished names for:

	(Absolute URI) + (optional fragment) //Absolute URI Ref
	(Absolute URI) + (fragment)		 //Those that actually have
a fragment.
	(Absolute URI)				 //Those that don't have a
fragment... Absolute URI.

ditto with relative variants, ditto but agnostic about being absolute or
relative.

--

[skw-2002-08-14-03]

I am also very wary about asserting that the thing identified by
URI+fragment is a resource (which is what happens once you accept the
redefinition of URI). On one level I could live with it justified on the
basis that anything with identity can be a resource (RFC 2396 says something
like that). 

However, resources can have fragments, and if I have a resource identified
by the URIRef http://example.com/someResource#otherResource, how do I
reference a fragment of that resource (assuming it has one)? The URI syntax
does not provide me a way to do that... so maybe one heads off may be to map
the name of this resource into some new URI scheme eg.
resource:http://example.com/someResource?frag=otherResource so that it can
now attract further fragment IDs. The particular design would need more care
so that it would recurse nicely. But that feels like a horible kludge.

Anyway... bottom-line. On the TAG telcon, we did discuss distinguish between
the sort of thing that a URI references and the sort of thing that a
URI+fragId references. I think there was consensus (although I'm not sure we
really tested it) that need distinguish terms for the referent... but I
think it would be folly to use the term 'resource' to denote the sort of
thing referenced by a URI+Frag since that is commonly held to be the sort of
thing that is referenced by a URI.

I'd suggest the terms: part; part_resource; resource_part; fragment;
fragment_resource; resource_fragment; particle (cf. sub-atomic partical with
resources as atoms).

--

Walkthrough
-----------

Introduction/Limits of Document
-------------------------------

[skw-2002-08-14-04]
"This document does not address architectural design goals covered by
targetted W3C specification:"

I'd like to be sure that we at least idenfity the holes that are filled
elsewhere, rather than saying there are a bunch of holes address in these
other places... go figure... ie. if there are important architectural
principles captured in the these other works they should at least be echoed
in in reference section we have with references to the relevant
specifications for further detail (whether technical rationale or
tutorial...).

Section 1.1
------------

[skw-2002-08-14-05]

I'd inarticulately echo many some incomplete subset of the things Larry
Masinter comments on in [1].

[1] http://lists.w3.org/Archives/Public/www-tag/2002Aug/0143.html

--

Section 1.2
-----------

[skw-2002-08-14-06]

Really would much prefer the precision of "Absolute URI" or "Absolute URI
Reference" (depending on how we resolve the nature of the sort of things
pointed to by URI references with and without fragmentIDs) to the
redefinition of URI and the mental gymastics require to apply the unfamiliar
usage of the term URI. [signed bear of little brain].

--

[skw-2002-08-14-07]

"Valid use of URI:... it is unambiguous what resource you are refering to." 

This is stated as a factual truth... but I'm not sure that it is. Counter
example: http://localhost/index.html well maybe it's not ambigous to 'me'
and may be its not ambiguous to 'you' what resource 'I' am refering to, but
it's not a resources that is identifiable by 'you' using the same URI as
'me'. Maybe there is a 'relevant protocol specification' that forbids 'my'
use of this URI.

--

Section 1.3.1
-------------
[skw-2002-08-14-08]

"Consistent Representations: ...to the extent possible representations
SHOULD be equivalent..."

This feels very tentative and weak. I think it needs to be stated more
strongly.

Section 1.4.1
-------------
[skw-2002-08-14-09]

"On the other hand, http://localhost/ and file:/etc/hosts each identify one
resource, but that resource is "local" to a particular computer. It is valid
to use a URI such as file:/etc/hosts on a given computer, and even on
several computers, if you are confident that all of those computers are
running the same type of operating system."

A couple of comments here.... I don't think the test for validity of use of
a URI like file:/etc/hosts should be based on type of operating system...
certainly in a document about the architectural principles of the web.

I also think that this little 'stanza' exposes an interesting question about
the relationship between a concept an a resource.  The URI file:/etc/hosts
could be thought of as labeling a single concept "The file on the local
filesytem named /etc/hosts." However, on each 'system' that 'dereferences'
that URI the referenced resource is a different file. One could square this
by saying that no... this is all one resource with many representations that
the representation that gets retrieved/accessed is context dependent. ie. it
is the representation and not the resource that varies with context. 

--

Section 1.5.1
-------------

[skw-2002-08-14-10]

"This type of indiscrimate use..." 

'Indiscriminate' seem an uncomfortable adjective to use. How about "This
type of inappropriate re-use..."






> -----Original Message-----
> From: Ian B. Jacobs [mailto:ij@w3.org]
> Sent: 13 August 2002 21:30
> To: www-tag@w3.org
> Subject: 13 Aug Arch Doc available for review
> 
> 
> 
> Hello www-tag,
> 
> The TAG invites your comments on the latest draft
> of the Architecture Document [1]. The TAG expects
> to publish a first public Working Draft (on the
> TR page) of the Architecture Document in a few weeks
> and would like material feedback on the current draft.
> 
> The TAG does not commit to responding to every comment;
> this is not a formal call for review. The usual TAG
> policy [2] regarding email on this list is in effect.
> 
> Please be concrete in your comments. Propose alternative
> language. Avoid sustaining long threads.
> 
> Chapter 1 ("Identifiers and Resources") may deserve the
> most attention -- it has received a lot more attention
> from the TAG than the other chatpers. On the other hand,
> concrete suggestions for how to structure the other
> chapters could also help us improve the first public
> draft.
> 
> Thank you,
> 
>    - Ian
> 
> [1] http://www.w3.org/2001/tag/2002/0813-archdoc
> [2] http://www.w3.org/2001/tag/#tag-attn
> -- 
> Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
> Tel:                     +1 718 260-9447
>

Received on Wednesday, 14 August 2002 14:08:13 UTC