- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Mon, 11 Nov 2002 17:53:26 -0000
- To: "'Ian B. Jacobs'" <ij@w3.org>
- Cc: www-tag@w3.org
Ian, 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. Regards Stuart -- Introduction: ------------- 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 context-free.] 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 ------------------------------ Editorial: "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." Picky: 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 meaning. 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 Namespaces. 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