Re: entity header

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

Received on Friday, 2 January 2004 18:10:40 UTC