Re: Representation header

Agreed. I'd go further and say that because of this, there's no need to 
have a direct relationship between the MIME headers and those 
represented in the XML. That said, the XML metadata should be used to 
generate the MIME headers properly when creating a MTOM message out of 
a non-MTOM message.

This should be easy to do in the case of a Representation header, 
because the metadata has a defined relationship with the data (i.e., 
the <mtom:Representation> element's structure and semantics are known). 
To make this possible with in-body mtom:Include, we will probably have 
to dictate where to find the metadata for optimisation candidates 
(e.g., as attributes on the parent element). If they aren't found, 
we'll have to default to application/octet-stream and other sensible 
defaults.

The task of creating a non-MTOM message out of a MTOM message is much 
simpler, because the MIME headers are only used to come up with the 
data (e.g., if there's content-transfer-encoding, etc.) that then needs 
to be encoded into XML; they're not surfaced in the XML because the 
metadata that's interesting to the application is already there.


On Nov 6, 2003, at 8:17 AM, Yves Lafon wrote:

>
> I shouldn't have used "All those metadata". I really meant that some
> metadata are transient and invisible to the application when the 
> message
> is serialized (and, for example, sent to a mail server not 8-bit 
> capable).
>
> I fully agree that in most cases, the metadata are seen at the 
> application
> level and therefore should be in the SOAP infoset, this is the case 
> when
> we embed a "cached" version of a http URI.
>
> (just sent that mail to clarify this to those not at the conf call)