- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Mon, 18 Oct 2004 14:52:18 -0400
- To: www-tag@w3.org
- Message-id: <87pt3fg8pp.fsf@nwalsh.com>
/ Sandro Hawke <sandro@w3.org> was heard to say: |> / Sandro Hawke <sandro@w3.org> was heard to say: |> [...] |> | Some of us think that an HTTP "200 OK" |> | response on a GET or HEAD for some URI means it identifies an |> | information resource |> |> Yeah, but some people don't think that. There is not consensus on |> whether or not http://example.com/dog must identify only an |> information resource. I see no evidence to suggest that any amount of |> discussion will ever achieve consensus on this point. | | It would be easy for everyone to drop the issue if this were a "coin | flip" decision, where things work pretty much the same either way, and | anyone who thorougly studies both sides can see that. But that's not | the case here. Here it seems to each side as if the other side is | merely ignorant of the big picture, and with a bit of education | they'll come around. /me shrugs I stand by my assertion. I've seen no evidence that suggests (to me) that further discussion will lead to consensus. Some people believe X because they've thought about it a lot and reached the conclusion that X is true. Other people believe Y because they've thought about it a lot and reached the conclusion that Y is true. X and Y are not compatible. Life is hard. |> | So from a process perspective, having Information Resource defined |> | turns httpRange-14 into pretty much a Yes or No question, although I'm |> |> I think httpRange-14 is a yes or no question no matter how you define |> (or even if you bother to define) information resource. The answer is: |> the community does not agree on what the answer is. | | I dare say the question has never been put to "the community" in a | coherent way. Well, it's sure had a lot of discussion in a lot of places. | Something like this: | | Try to imagine that each working HTTP URL is the name of some | particular conceptual entity. Some of these entities may be easy | to conceptualize, such as a blog or price list, while others may | be less obvious. (What exactly does "http://www.google.com" or | "http://www.uroulette.com/visit"[1] name?) | | Remember that web protocols support format and language | negotiation, so that from a single URL you may obtain content in | different languages and in different formats, depending on your | browser settings and capabilities. And of course content changes | over time. | | Now the question: are there any generalization you can make | about all such entites? If so, what are they? What properties | do all such entities have? Can you think of a good name for | this class of entities? | | [1] Visiting this URL results in a redirect to a random other | location. I doubt that question is pointed enough to answer httpRange-14. | I'm also not sure what the community is. Maybe the W3C AC Reps would | be fun place to start. :-) Call it a W3C Referendum. Or maybe we | could try it as a slashdot quick. Ha! How many people would check | "I'm pretty sure Cowboy Neil is a web page" ? Yeah, well, I'm not sure what the community is either. Everyone who reads www-tag and/or xml-dev maybe. | Seriously, I'm writing this while procrastinating about answering this | for myself in Ontaria. I need a tab on which to display information | about any resource for which dereference worked, and I'm not sure what | users are going to want to see on that tab. I'm also not sure what to | call it (ie what the class name is), but I'm leaning towards "Document". How about 'Response Headers' :-) Be seeing you, norm -- Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc. NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Received on Monday, 18 October 2004 18:52:46 UTC