- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Thu, 6 Nov 2003 09:26:19 -0800
- To: Yves Lafon <ylafon@w3.org>
- Cc: noah_mendelsohn@us.ibm.com, Anish Karmarkar <Anish.Karmarkar@oracle.com>, Martin Gudgin <mgudgin@microsoft.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
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)
Received on Thursday, 6 November 2003 12:27:11 UTC