Xiaoshu Wang wrote: >>> Let me put it in this way, if I have a resource R that is composed >>> with two parts A and B. uri(R) should always return the >>> representation of R, ie., >>> (A+B) right? If as you suggested, the uri(R) would have three >>> possible >>> results: >>> (1) A >>> (2) B >>> (3) A+B >>> >>> It fundemantally breaks the purpose of URI, don't you think? >>> >> I don't think so, no. A, B and A+B could all be >> representations of the same resource. If the client only >> needs A, what's the point in sending B over the wire too? >> > > Of course, the intention for saving network bandwidth is good. But to solve > one problem may potentially a lot of other problems. IMHO, the tradeoff for > this particular case is just too much. > The feature is hardly implementable with traditional file-based webservers, but what's the trade off? They may ignore the Accept-Vocabulary header as most webservers ignore the Accept and the Accept-Language header. If you send the following HTTP-Request to dannyayers.com: GET / HTTP/1.1 Host: dannyayers.com Accept: application/x-turtle Accept-Language: en You'll get a lot of triples your client probably can't deal with, if Danny turns on inference on the server you would get many triples the client could infer itself, as more RDF is transferred over HTTP plain serialization negotiation will no longer be enough. reto
Received on Tuesday, 25 July 2006 17:49:22 UTC