- From: Tim Bray <tbray@textuality.com>
- Date: Wed, 05 Feb 2003 11:50:50 -0800
- To: WWW-Tag <www-tag@w3.org>
1.3 Typo - Coneg should be Conneg, right? ================================================= Constraint/Good Practice/Principle This still needs work. Maybe we're trying to have too many buckets? I substantially disagree with many of the current assignments; not sure how to proceed on this one. Also, we need to be clear on what our objective is in this taxonomy, i.e. what is the benefit for the reader of this document? =================================================== 2. intro When you first introduce URI schemes seems like you might as well tell the world that they're identified by :-delimited prefix, i.e. there's no magic here. =================================================== 2.1 "When one resource refers to another" - I think we mean is when a resource representation contains the URI of another resource, right? ====================================================== 2.1.1 Identity questions The third paragraph and list of bullet points feel redundant to me, consider just losing it. The first two paragraphs are very good and make an important point. ================================================================= 2.2.1 Comparing Clearly we have significant overlap with my uri-comp draft. So we need to decide what the disposition of that is. Possibilities: (a) its text migrates into webarch (b) it is a standalone document that webarch points it (c) its text migrates into RFC2396 In cases (b) and (c) section 2.2.1 could be vastly cut down with the text used by reference. And perhaps the principle can be generalized to say "carefully consider issues involved in URI comparison before deciding whether they are interchangeable or equivalent". ============================================ 2.2.2 Deferencing The last paragraph, has a yawning discontinuity between the first and second sentences. The 1st talks abstractly about metadata. The second leaps into details about the (so far undefined) media type. I think we need to be more specific that we're actually talking about MIME/HTTP headers. No quibble with the content though ============================================================= 2.2.4 Consistent Representations The first paragraph is a big problem - I strongly suggest removing it. I don't know what "authoritative meaning of a resource" means. All that the HTTP scheme tells you is that if you want to ask for a representation of a resource, here's the protocol you use to get it. The 2nd para starts well and reads well. 2nd para - "Consider the previous URI" - er previous how so? I think there's an extra word here. Last para of section 2.2.4 is also in need of work. The section beginning "In this document we do not talkk about the meaning..." at least needs to be in its own paragraph. Also I would like to have it removed for the same reason the first paragraph needs to go. =========================================================== 2.3 - the discussion of "myscheme:blort" points out correctly that someone else might be using "myscheme". But there are a million other problems with doing this, the largest of which is that there can be no expectation that any software out there will do anything useful with it. This paragraph could benefit from a bullet list of Reasons Not To Do This Stupid Thing. ======================================================= 3. Representations In the 2-part definition of a resource, is "Internet Media Type" really all there is? There is also other useful stuff in the HTTP headers that affects the way software processes representations.
Received on Wednesday, 5 February 2003 14:50:51 UTC