On 7/26/06, Xiaoshu Wang <[EMAIL PROTECTED]> wrote:
--Reto, > > The HTTP protocol is not designed to do content partition. > Not sure, after all we have Byte Ranges for binary content. It is for the purpose of transportation. Again, let's use UPS as an example, byte range is like, O.K. give me the first three package first. But not give me all the packages that contains books. Because what is inside a package is irrelevant to their tasks.
How does UPS deal with Accept-Language?
> It's not about about (arbitrary) queries but about selecting > the representation. Representation of a resource may be > incomplete, so if G is an appropriate representation of R > every subgraph of G is as well. What is the definition of "appropriate"?
Whatever the server thinks best. By your logic, a picture of your
forehead is an appropriate representation of a face? Selecting partial representation is a totally different matter from selecting different kinds of representation.
How do you define "partial representation"? As you keep insisting, such issues are not relevant to the transport (but the transport can relay related information). A forehead may be a perfectly good representation of a face to an agent that is only interested in frown lines. The representations of a typical weblog change from one week to the next. Without additional constraints in your example, tomorrow you might get a completely different person's face.
Of course, in an open world, no one has the complete information about a resource. So, all RDF is only a "partial" representation of the resource. However, if this "partial" information is a complete or adequate representation of the resource is the choice of the resource owner, who must understand the consequence of his/her choice.
In part (!), yes, but noting that what the user of the data considers adequate/complete may be very different than what the resource owner has in mind.
Take HTML page as an example. If I want to put up a long article on the web, I can elect to put them in two ways: 1. As one big html page under one URI 2. As multiple pages, each of which has a URI. It is up to me to weight the tradeoff and make appropriate decision. It is an engineer/design issue but not a transportation issue.
True. But if the client is a small-screen device, a shorter version of the page may be requested (and may be delivered). Henry's example snipped, but I do think Reto's onto a good inference things. That's a great example of where some form of negotiation could be useful. If the client hasn't many cycles available, let the server do a bit more work. Xiaoshu, believe it or not I'm still not entirely sure where your objections lie. Would you be against negotiation information being part of the payload? That may prove a better approach, but in the general case I'd suspect you'd end up with something SOAP-like, not using HTTP to its full advantage. HTTP is designed to be extensible, it includes negotiation capabilities on syntax, why shouldn't it happen on semantics? Cheers, Danny. -- http://dannyayers.com
