RE: Proposal for multi-reference support in MTOM

Marc,

I have now read your proposal, my apologies for the delay. 

I have to say that I don't think it has any benefit over the
Representaion header approach. I still have to add an attribute to my
element. In your proposal it's a mtom:ContentID, in the Representation
header case it's any attribute you like provided it's of type xs:anyURI.
In both cases I can deal with multiple references and only send a single
copy of the data.

Where you proposal diverges is that I think it makes life very hard for
intermediaries. It essentially requires them to parse the whole message,
looking for xbinc:Include elements and/or mtom:ContentID attributes. I
don't want intermediaries to have to trawl through headers not targetted
at them or the body. And with your proposal they would have to do that.
With the Representation header we can target given representations at
specific roles, and also have Representations intended for 'everyone' by
targeting them at 'none'.

Regarding signatures, I regard it as a feature, not a bug, that I can
sign the reference seperately from the referenced data. With the
Representation header I 
essentially get to choose. I can sign the reference, the data or both.

In summary, I am opposed to this approach. I still think that 1:1
correspondence between xbinc:Include elements and MIME parts is the
right way to go.

Gudge

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Marc Hadley
> Sent: 12 November 2003 12:47
> To: Xml-Dist-App@W3. Org
> Subject: Proposal for multi-reference support in MTOM
> 
> Here's a proposal for an extension to the current MTOM 
> formulation to offer better support for multiple inclusion of 
> the same data. The proposed extension  has the following properties:
> 
> - Preserves MTOM semantics of attachment inclusion in SOAP 
> message infoset
> - Supports existing 'Include' and 'Representation' semantics, 
> use of extension is optional
> - Supports multiple inclusion of attachments without 
> replication of data in the serialized form
> - Multiply included data replicated in message infoset, 
> signatures over elements containing such data include 
> attachment data rather than a reference to the data as woud 
> be the case when using a Representation approach.
> 
> 
> Infoset Form
> ============
> 
> This section shows via an example the infoset of a message 
> after the binding has performed the MTOM deserialization 
> (described later). XML 1.0 is used as the most convenient 
> syntax to express the infoset but this should be considered a 
> purely abtract model of the message content.
> 
> <env:Envelope xmlns:env="..." xmlns:mtom="...">
>    <env:Body>
>      <app:Stuff xmlns:app="...">
>        <app:Thing1 mtom:ContentID="someURI">
>          some base64 text
>        </app:Thing1>
>        <app:Thing2 mtom:ContentID="someURI">
>          some base64 text
>        </app:Thing2>
>        <app:Thing3>
>          some base64 text
>        </app:Thing3>
>      </app:Stuff>
>    </env:Body>
> </env:Envelope>
> 
> Note that the same base64 data is included as the content of 
> the Thing1 and Thing2 EIIs, this is indicated by the value of 
> the mtom:ContentID attribute being the same for both. Thing3 
> has no mtom:ContentID indicating that the optional 
> multi-reference extension is not being used for the content 
> of this EII.
> 
> 
> Optimized (MIME) Wire Form
> ==========================
> 
> This section shows via an example the serialized form of a 
> message using the MIME based MTOM.
> 
> Content-type: multipart/related; boundary="someBoundaryString"
> 
> --someBoundaryString
> Content-Type: application/soap+xml
> 
> <env:Envelope xmlns:env="..." xmlns:mtom="...">
>    <env:Body>
>      <app:Stuff xmlns:app="...">
>        <app:Thing1 mtom:ContentID="someURI">
>          <mtom:Include href="someURI">
>          <!-- depending on how mtom:ContentID is defined, the 
> Include/@href may be redundant -->
>        </app:Thing1>
>        <app:Thing2 mtom:ContentID="someURI">
>          <mtom:Include href="someURI">
>        </app:Thing2>
>        <app:Thing3>
>          <mtom:Include href="someOtherURI">
>        </app:Thing3>
>      </app:Stuff>
>    </env:Body>
> </env:Envelope>
> 
> --someBoundaryString
> Content-Type: image/png
> Content-ID: someURI
> 
> binary picture data
> 
> --someBoundaryString
> Content-Type: image/png
> Content-ID: someOtherURI
> 
> binary picture data
> 
> --someBoundaryString--
> 
> 
> Schema Types
> ============
> 
> <complexType name="OptimizationCandidate">
>    <simpleContent>
>      <extension base="xsd:base64Binary">
>        <attribute name="ContentID" type="xsd:anyURI"/>
>        <attribute name="MediaType" type="xsd:string"/>
>        <!-- other attributes we define -->
>      </extension>
>    </simpleContent>
> </complexType>
> 
> Terminology
> ===========
> 
> The following terminology is used in the description of the 
> serialization and deserialization algorithms:
> 
> Optimization candidate:
>    EII of type xsd:base64 or mtom:OptimizationCandidate.
> 
> Matching MIME part:
>    MIME part whose content-id and/or content-location headers 
> (TBD specify exact matching criteria) match an 
> OptimizationCandidate/@ContentID.
> 
> Content:
>    base64Binary child CIIs of an optimization candidate (excludes AII
> children)
> 
> 
> Infoset to Wire Serialization
> =============================
> 
> For each optimization candidate in the SOAP message
>      - if no matching MIME part exists then create a matching 
> MIME part 
> from the optimization candidate's decoded content and AIIs
>      - replace the content of the optimization candidate with a child 
> mtom:Include EII
> 
> 
> Wire to Infoset Deserialization
> ===============================
> 
> For each mtom:Include EII
>      - replace the mtom:Include EII with base64 encoded attachment 
> content
> 
> --
> Marc Hadley <marc.hadley@sun.com>
> Web Technologies and Standards, Sun Microsystems.

Received on Tuesday, 18 November 2003 21:02:46 UTC