- From: Williams, Stuart <skw@hp.com>
- Date: Mon, 29 Sep 2003 16:41:45 +0100
- To: "'Ian B. Jacobs'" <ij@w3.org>
- Cc: www-tag@w3.org
Hello Ian, > -----Original Message----- > From: Ian B. Jacobs [mailto:ij@w3.org] > Sent: 26 September 2003 21:06 > To: www-tag@w3.org > Subject: Arch Doc: 26 September 2003 Editor's Draft <snip/> > ========================================================== > > Comments from Stuart > http://lists.w3.org/Archives/Public/www-tag/2003Sep/0128.html > > <snip/> > 2) Endnote 2 requires clarification. This is based on text > from Roy. > > "User agent configurations are usually defined by URI scheme, > with exceptions defined by further substring matches within > the URI." > > http://lists.w3.org/Archives/Member/tag/2003Jul/0079 Ok... I think I see the disconnect. The text at EndNote 2 says "User agent configurations are usually defined by URI scheme, with exceptions defined by further substring matches within the URI." But I do not see and would not expect to see any user agent configurations defined by a URI scheme (specification). I think what Roy was saying that such configuration as a UA may allow is often available on a per-URI scheme basis. If that is the case then a simple rewording will suffice... that said, I also don't think it adds much to the document and would be happy to see the endnote dropped from the document. > > 3) Endnote three and use of other protocols than HTTP for > http URIs. Reference RFC 2396, section 1.2: > > "Although many URL schemes are named after protocols, this > does not imply that the only way to access the URL's resource > is via the named protocol. Gateways, proxies, caches, and > name resolution services might be used to access some > resources, independent of the protocol of their origin, and > the resolution of some URL may require the use of more than > one protocol (e.g., both DNS and HTTP are typically used to > access an "http" URL's resource when it can't be found in a > local cache)." > > Proposal: Added reference. I see no added reference! > 4) Cause/effect backwards in describing "link". > > I must be missing a subtle point. I don't know how (in the > Web arch) to detect that two resources are linked until > a URI ref appears in a representation. [NB this was tagged picky] The text says "When a representation of one resource refers to another resource with a URI, a *link* is formed between the two resources." A strict reading of this suggest that a link between resources if formed only when (after) a reference has been made in a representation ie. implies that two resources cannnot be linked even if a representation of the refering resource has never been minted or exchanged. It seems to me that the reason a representation might reference another resource is because the resources are linked rather than the resources are linked because a representation of one make reference to the other. > 5) 2.4.1 Secondary Resources... > > SW: "Knowledge of the media-type associated with a frag-id is > implicit in the account given here. This seems to be at odds > with the use of URI references as opaque identifiers as > typified in RDF/Semantic Web. ie. we only give an account here > of the use of fragment ids in relation to a representation with > a known media-type" > > IJ: Does the following sentence which appears in the next > paragraph suffice? > > "The presence of a fragment identifier agent in a URI does > not imply that a retrieval action will take place." > > Or, from [URI]: > > "As with any URI, use of a fragment identifier component does > not imply that a retrieval action will take place. A URI with > a fragment identifier may be used to refer to the secondary > resource without any implication that the primary resource is > accessible. However, if that URI is used in a context that > does call for retrieval and is not a same-document reference > (section 4.4), the fragment identifier is only valid as a > reference if a retrieval action on the primary resource > succeeds and results in a representation for which the > fragment identifier is meaningful." Hmmmm don't know... will think some more. <snip/> > 7) Good Practice Note: Content Negotiation With Fragments. > > SW: I prefer the wording of the Good practice note "Content > negotiation with fragments" from the current TR page draft: > http://www.w3.org/TR/2003/WD-webarch-20030627/#http-conneg-frag > > 8) 2.5.2 > > SW: Step 5&6 refer to "Content-type field": s/field/header/ > > Looking at RFC2616, I find, for example in 9.2: > > "If the OPTIONS request includes an entity-body (as > indicated by the presence of Content-Length or > Transfer-Encoding), then the media type MUST be indicated by > a Content-Type field." > > No change. Ok... > 9) 2.6 Persistence and Ambiguity > > No text proposed; no change. Ok... but I trust that the issues raised by the comment remain open for discussion. > > 10) 4.5 Binary and Textual Data Formats > > SW: "I wonder if some of the current discussion re text/*+xml > and application/*+xml should be reflected here. The bias in 4.5 > is to promote XML as textual data format, so perhaps some > careful words are in order around the TAG disposition wrt > text/*+xml. Maybe a forward reference to 4.10.6 would cover > some of this." > > There is a forward ref in first sentence. Not sure what else > to add before more discussion in TAG. The forward reference is to 4.10 as a whole (or maybe just to the header for 4.10 - never can tell the difference :-)). The points was that in the current discussion, if I have kept upto date, there is a move toward deprecation of text/*+xml. This seems somewhat ironic when juxtaposed with encouragement to use XML because of its textual nature. Maybe we have to let the dust of that thread of discussion settle out. <snip content="responses to others"/> > -- > Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs > Tel: +1 718 260-9447 > Thanks, Stuart --
Received on Monday, 29 September 2003 11:43:51 UTC