Re: entity header

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."

Received on Wednesday, 17 December 2003 07:03:55 UTC