Re: entity header
Yves Lafon <[email protected]>
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 7 Jan 2004, Mark Nottingham wrote: > Counter-proposal: > > <x:Entity> > <x:metadata> > <x:header name="bar">baz</x:header> > <x:header name="boo">1</x:header> > ... > </x:metadata> > <x:content> > ... > </x:content> > </x:Entity> > > with extensibility in attributes as well as children of entity and > metadata. It is ONLY a means of representing a MIME(-like) entity; > application semantic is not implied. So you mean you want only the headers of the reply and no interpretation of them? From what I understood before, having a normalized way to say "this is of type image/jpeg" instead of knowing all the header form of all protocol is something desirable (hence the meta/rawmeta proposal). Also in some case the headers of the request might be used. I'm ok to leave of the intent that seems to be more confusing than anything else. > > > > On Dec 9, 2003, at 1:52 PM, Yves Lafon wrote: > > > > > 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." > > -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."