Re: Proposed resolution for issue 440

On 6 Nov 2003, at 14:33, Martin Gudgin wrote:
>>
>> For my part I think that requiring every attachment to have a
>> corresponding xbinc:Include is too restrictive because it
>> would effectively disallow use of existing attachment
>> techniques.
>
> I see this as a feature not a bug.
>
Interesting.

>> MTOM provides one approach to attachments but I
>> fail to see why it shouldn't be composable with alternative
>> mechanisms.
>
> Because the alternatives are not architecturally sound.
>
That's quite a claim. MIME based systems have been functioning quite 
well without MTOM for some time now...

>> What gets broken in MTOM by allowing this flexibility ?
>
> The fact that the entire message is not an infoset.

And that's a problem for MTOM because ... ? Where you want the MTOM 
abstraction to apply then you can use the MTOM facilities, where that 
isn't important then you can use something else. Why does it have to be 
all or nothing ?

>>>
>> The same reason we need an Include element in the current
>> formulation:
>> we need something to hang the MTOM processing magic on.
>
> I don't think multiple references need any processing magic beyond 
> what xs:anyURI and the Representations header provide.
>
Only using some application specific referencing mechanism would mean 
that you would lose the automatic benefits of the MTOM abstraction at 
the points where the reference is made. E.g. If I sign some part of a 
message that contains an xbinc:Include then I effectively sign the data 
in the referenced attachment. If I sign some part of a message that 
contains an application specific reference then I just sign the 
reference. The suggestion I made for splitting the existing Include 
into a soap header based anchor plus one or more references would unify 
the model and support multiple references cleanly.

> I am fine with restricting freedom along one axis while allowing it in 
> another.
>
Me too, but I would swap the axes.

Marc.

>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM]
>>>>>> Sent: 06 November 2003 16:04
>>>>>> To: Martin Gudgin
>>>>>> Cc: Xml-Dist-App@W3. Org
>>>>>> Subject: Re: Proposed resolution for issue 440
>>>>>>
>>>>>> On 5 Nov 2003, at 12:48, Martin Gudgin wrote:
>>>>>>>
>>>>>>> Proposed resolution:
>>>>>>>
>>>>>>> Each MIME body part (except the root) MUST be referenced
>>>> by exactly
>>>>>>> one xbinc:Include element.
>>>>>>>
>>>>>> I think requiring every attachment to have a corresponding
>>>>>> xbinc:Include is too restrictive. Adopting this approach would
>>>>>> effectively disallow use of existing attachment techniques. MTOM
>>>>>> provides one well specified approach to attachments but it
>>>> shouldn't
>>>>>> prevent someone from using an alternative. MTOM should support
>>>>>> composition with other attachments techniques rather than
>>>> rule them
>>>>>> out. I don't think the MTOM spec has much to say about
>> attachments
>>>>>> that aren't referenced using an xbinc:Include element but it
>>>>>> certainly shouldn't disallow them.
>>>>>>
>>>>>> I also think there are many cases where a single
>>>> attachment would be
>>>>>> logically included in multiple places in a message and
>>>> that we should
>>>>>> address this case in a normative manner rather than
>> defer to some
>>>>>> application specific means of supporting this.
>>>>>>
>>>>>> Perhaps we could refactor the include mechanism into two separate
>>>>>> components: a SOAP header block that forms an anchor for
>>>> references
>>>>>> to an attachment plus a schema type or element/attribute
>>>> that is used
>>>>>> to refer to the anchor header blocks where the data they
>> refer to
>>>>>> should be logically included. E.g.
>>>>>>
>>>>>> <s:Envelope xmlns:s="...">
>>>>>>    <s:Header>
>>>>>>      <xbinc:AttachmentAnchor xmlns:a="..." id="id1"
>>>> href="cid:..."/>
>>>>>>    </s:Header>
>>>>>>    <s:Body>
>>>>>>      <d:document xmlns:d="...">
>>>>>>        <picture xbinc:IncludeRef="id1">
>>>>>>        </picture>
>>>>>>      </d:document>
>>>>>>    </s:Body>
>>>>>> </s:Envelope>
>>>>>>
>>>>>> Only one AttachmentAnchor would be allowed per MTOM attachment.
>>>>>> Following MTOM processing the picture element would
>>>> logically contain
>>>>>> a
>>>>>> base64 encoded version of the attachment referred to by the
>>>>>> corresponding Attachment Anchor and would maintain the
>>>>>> xbinc:IncludeRef aii.
>>>>>>
>>>>>> Marc.
>>>>>>
>>>>>>>
>>>>>>> [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440
>>>>>>>
>>>>>> --
>>>>>> Marc Hadley <marc.hadley@sun.com>
>>>>>> Web Technologies and Standards, Sun Microsystems.
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Marc Hadley <marc.hadley@sun.com>
>>>> Web Technologies and Standards, Sun Microsystems.
>>>>
>>>>
>> --
>> Marc Hadley <marc.hadley@sun.com>
>> Web Technologies and Standards, Sun Microsystems.
>>
>>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.