W3C home > Mailing lists > Public > www-tag@w3.org > November 2002

RE: [Publication] 29 Oct 2002 Arch Doc

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Mon, 11 Nov 2002 17:53:26 -0000
Message-ID: <5E13A1874524D411A876006008CD059F04A07114@0-mail-1.hpl.hp.com>
To: "'Ian B. Jacobs'" <ij@w3.org>
Cc: www-tag@w3.org


Detailed comments below. Of these, the ones related to URI terminology
(request a commitment to being aligned with a successor to 2396) and URN
Namespaces, should be addressed before we publish a new WD. Easy editorials
should be done. More philosophical points can be resolved later.



I like the Identification, Representation and Interaction split. One of the
things Roy has also spoken about, at least in conversation, is application
state. I'm tempted to suggest that the third component be "Interaction and
Application State" - just a thought!

1.1 Audience
References RFC2026 for process that the IETF follow. I think it might be
better to reference the RFC Index for more information on RFCs rather that
the process that creates them. Alternatively, it might be better to identify
particular RFCs of import (2396, 2616,...)

1.3 Summary of...
a) Consistent URI: "Indiscriminate use of a URI..." doesn't really
communicate what this one is about. "Inconsistent use of a URI undermines
its value to the systems (and people) that use it. Within a given context a
URI is expected to consistently identify the same resource."

[This latter acknowledges the possibility of multiple contexts, and that the
'meaning' of a URI is/should be unambiguous within some context of use...
but may be different in different contexts. Larry Masinter has been making
this point (I think) with reference to a paper on "Transfers of Meaning"
[1]. This might be objectionable if you regard the URI->Resource mapping as

b) Coneg with fragments: I think this one is difficult to express. I think I
would prefer a SHOULD rather than a SHOULD NOT, and suggest "When
representations of a resource are available in multiple formats, fragment
identifiers in resource references SHOULD be used in a way that identifies a
consistent part of a representation."

Last paragraph of section 4.1 in RFC2396 says (trailing clause):
   A fragment identifier is only meaningful when a URI reference is
   intended for retrieval and the result of that retrieval is a document
   for which the identified fragment is consistently defined.

2 Identification and resources
"Several URI schemes incorporate into this syntax some identification
mechanisms that pre-date the Web"

Reword as: "Several URI scheme incorporate identification mechanisms that
pre-date the Web into this (generic URI) syntax."

TEL URIs identify telephones? I don't think so... they might identify a
collection of telephone connection endpoints (wall sockets), but even then
those are easily associated with a different telephone number (office moves,
house moves, telephone number changes).

Last paragraph on URI terminology difference. I would like to see a
commitment on the part of W3C/TAG to use terminology that is consistent with
any updates to 2396. It's fine if the process of updating 2396 results in an
agreed change in the use of terms. IMO it would not be fine for our work and
the successor to RFC 2396 to use the same terms with subtle differences in

2.1 Resources, URIs and shared information space
Uses the term 'addressable' repeatedly throughout. We speak of 'identifiers'
and 'references', of 'retrievability' and 'dereference'. Do we really need
the word 'addressable'?

2.2 Operations on URI

"2 Interaction with resources". Not sure that this really counts as
Operations on URI. It is certainly a use of URI. I think the operation on
the URI in such circumstances is 'dereference' effectively maps from the URI
to the referenced resource.

2.2.1 Comparison of Identifiers
Repeated avoidance of using the terms "URN Namespace" and URN Namespace
Identifier (NID)". I would prefer to see the URN RFC properly referenced and
the terms defined therein used properly.

2.2.2 Interactions with resources
Firstly this might belong in the section on Interaction.

"To dereference a URI is to interact with the resource it identifies."
Hmmmm.... I think interaction involves dereference, but dereference is to
(repeatedly if necessary) resolve a URI into a set of communication
parameters (access protocol, host addresses, port numbers...) as a precursor
to interaction. Conceptually it is moving from one end of a pointer (the
referencing end) to the referenced resource.

2.2.4 Consistent representations and persistence
"URI's represent as worldwide contract..." RFC2396 *might* represent such a
contract, but I don't think URIs do in and of themselves. I'm also not sure
URIs or RFC2396 say (or could be expected to say) how resources designated
by URI take on meaning. 

2.2.5 (See earlier comment on Inconsistent use of URI)

2.3 URI Schemes
Last sentence end "URN subclasses". Please use URN terminology... ie URN

2.5 Some Generalities...
"Some of these generalities do not hold..." seems a bit of an oxymoron. If
they don't generally hold, they are not generalities and should not be in
the list.

The list probably needs to be crisper (less fluff).


> -----Original Message-----
> From: Ian B. Jacobs [mailto:ij@w3.org]
> Sent: 30 October 2002 00:13
> To: www-tag@w3.org
> Subject: [Publication] 29 Oct 2002 Arch Doc
> Hello,
> I've made available the 29 Oct 2002 Architecture Document [1].
> This draft incorporates reviewers' comments and TAG
> discussion of those comments since the TAG's Sep 2002
> face-to-face meeting.
> This draft does not include substantial amounts of new
> text. However, there are some new notes in section 3
> (formats). I anticipate a new draft in the next week
> that will include new text from TAG participants.
> The list of changes [2] is available.
>   - Ian
> [1] http://www.w3.org/2001/tag/2002/WD-webarch-20021029
> [2] http://www.w3.org/2001/tag/webarch/changes#changes-20021029
> -- 
> Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
> Tel:                     +1 718 260-9447
Received on Monday, 11 November 2002 12:53:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:55 UTC