- From: Bullard, Claude L (Len) <clbullar@ingr.com>
- Date: Fri, 11 Jul 2003 13:15:35 -0500
- To: "'David Orchard'" <dorchard@bea.com>
- Cc: www-tag@w3.org
If one makes the definition contingent on observability, when the representation is returned, it is on the web regardless of the method used as long as a system method is used (thus REST). On the Web is not a permanent condition; it is a testable condition. So it is the same for the resource or the representation. One never has to say what the web is; as Dan points out, the architecture document tells us that. I disagree with Dan that it tells us what is "on the web", just the means of making the observation of the truth or falsity of the assertion. len From: David Orchard [mailto:dorchard@bea.com] There are a number of aspects of "on the web". The one that I'm focusing on is whether the dereference operation requires a representation or not, and hence the relationship between the retrieved representation and the URI. In particular, a HTML FORM POST sends a representation to a URI, and retrieves a representation from a URI based upon the input representation. But the representation that is returned is not directly related to a URI, so that resource is NOT "on the web". And that's not a bad thing, just the way it is. You're focusing on the dynamic availability of the resource. I would say that there is some expectation, and I don't know how to qualify it, that the resource will be available. If cnn has an up time of 99.9999% of the time, we probably consider it "on the web". If cnn is only available 00.0001%, is it on the web? I don't know where the dividing line is. I'd prefer to avoid the "availability" aspect as I don't think we can say much. But we certainly can talk about whether it's even possible for the resource to be available. In the case that I mentioned, the form post result is never ever on the web.
Received on Friday, 11 July 2003 14:15:40 UTC