- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 9 Dec 2003 22:52:41 +0100 (MET)
- To: xml-dist-app@w3.org
Here is something that enable multiple behaviour. The rationale for having such entity header is related to UC2, embedding a representation of a resource (usually a web resource) to an endpoint that might or not be able to deference it. Also the capabilities are unknown, so the "generic HTTP cache behaviour" has to be possible (but not mandatory) Here is my proposal... <foo:Entity> <context> <request> <header name="Accept">application/soap+xml, image/svg+xml, image/jpeg</head> </request> </context> <rawmeta> <header name="Vary">Accept</header> <header name="Content-Type">image/svg+xml</header> ... </rawmeta> <meta> <property name="Content-Type">image/svg+xml</property> </meta> <processing> http://www.w3.org/2003/12/fullhttpcache </processing> <body>...</body> </foo:Entity> Where rawmeta is the metadata received, without requiring understanding it, meta being the one known (I suggest to put only common MIME headers, like Content-Type). And a processing EII pointing to a URI defining the default behaviour. If unknown we can propose the safe bahaviour of "get from the net and if it fail, use the copy". But we will need to explicit the different behaviours for each URI used. Do we need to put the request URI there as well? (in context). Note that I made a special case for a negotiated resource, where many things are needed. depending on the resource and the processing model used, most header can be absent, leading to a far mor simple version of it. Comments? -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Tuesday, 9 December 2003 16:52:45 UTC