Re: entity header
Mark Nottingham <[email protected]>
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <[email protected]> |
I tend to think we're just defining an XML structure whose semantic is "I can be transformed into a MIME entity, if you want to," and we want to when we do MIFFY<->plain XML conversions. Any other application-specific or infrastructure-specific semantic can be added by extending that structure, if necessary. On Dec 17, 2003, at 4:03 AM, Yves Lafon wrote: > > On Wed, 10 Dec 2003, Jacek Kopecky wrote: > >> Yves, all, >> >> this proposal is extremely complex (considering what I think we want >> to >> achieve). I'd suggest we split it into different syntaxes according to >> the processing URIs. > > Well, the goal was to allow very straightforward use of the attached > representation as well as more subtle processing (like aloowing the > receiving end to act as a HTTP compliant cache). Of course, processing > is > not mandatory (I should have changed <processing> to <intent> or > something > like that to clearly indicate that). > > >> Concretely, I'd define the foo: namespace as something like >> http://www.w3.org/2003/12/fullhttpcache and I'd remove the processing >> EII from the children of foo:Entity. > > Well, in that case an implementation that know only the > http://www.w3.org/2003/12/usethis will fail to recognize the entity > header. > With <intent>, an implementation that know only the "usethis" way of > processing this will just ignore the extra EII it doesn't need to know. > It is just a way to characterise what is attached, not a mandatory > "process it this way or fail" thing. > >> To cover the simple cases (see below), I'd define something as simple >> as >> >> <ns:Representation uri="..." xmime:mediaType="..."?> >> ... base64 data ... >> </ns:Representation> >> >> (remarkably similar to what PASWA proposed, I believe), with the >> semantics of "if the receiver is dereferencing the given URI and it >> thinks the presented representation will suit it, it may use it." >> >> The thing is, applications that need to receive resource >> representations >> along with the messages (because they are constrained in some ways) >> are >> usually hard-coded to work with the received representation no matter >> what, and the senders know that (are hard-coded, too) and send the >> right >> stuff. >> >> I don't see myself ever using the full foo:Entity (as proposed) in any >> kind of real SOAP application. For me, the immensely simpler >> ns:Representation would do. Therefore I suggest we consider both >> approaches in parallel, and I vote that we do not work further on the >> general foo:Entity stuff and that we continue with the limited >> ns:Representation. 8-) > > As said earlier, a valid implementation can just ignore things not > intended for its level of processing, and can be hardwired to do just > the > simple stuff if that's the only thing you need (for now). > > Imagine that you (well, not you ;) ) want to use SOAP+MTOM to carry > updates between distributed HTTP caches, the need of having the > fullhttpcache level might be good to ensure the content if updated the > right way. > > > >>> 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."