Re: entity header

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. 

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.

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-)

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/





On Tue, 2003-12-09 at 22:52, 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?

Received on Wednesday, 10 December 2003 04:25:58 UTC