W3C home > Mailing lists > Public > www-tag@w3.org > February 2003

Comments on 6 December webarch Editor's Draft

From: Tim Bray <tbray@textuality.com>
Date: Wed, 05 Feb 2003 11:50:50 -0800
Message-ID: <3E416B1A.1020000@textuality.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:16 GMT