Re: Sharing MTOM parts for identical leaf nodes

Isn't this SOAP encoding in disguise?

Sanjiva.

----- Original Message -----
From: <noah_mendelsohn@us.ibm.com>
To: <xml-dist-app@w3.org>
Sent: Saturday, September 27, 2003 6:31 AM
Subject: Sharing MTOM parts for identical leaf nodes


>
>
>
>
>
> Jacek and I had some private discussion of this over the summer, but I'm
> not sure whether it ever resulted in any public consideration by the WG:
>
> It occurs to me that in certain use cases the identical large binary might
> logically serve as content to multiple leaf nodes.  This could in
principle
> be done by reference to headers, but that changes the vocabularies and is
> not in all cases natural.  I wonder whether we should allow a smart MTOM
> implementation to point multiple xbinc:Includes to the same mime part
(I.e.
> use the same URI)?  Seems like a win to me, and I can quite easily imagine
> implementations that would know from the construction of the DOM or
similar
> structure that the content was identical.
>
> In any case, I think we should open an issue to make clear what the rule
> is, even if we just clarify that you must not link a given mtom part from
> more than (or perhaps less than?) a single xbinc:Include.  My current
> leaning would be to allow flexibility in both directions.  Multiple
> xbinc:Includes should be able to ref the same content, and it should be
> possible to carry content that is not referenced at all (e.g. to avoid the
> need for reference counting, or to maintain certain kinds of signatures,
> even if a header with a reference is removed.)  That said, I wouldn't
> expect many implementations to avail themselves of the permission to send
> large useless content,  but I think the sharing makes sense.
>
> New issue?
>
> Thanks.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>

Received on Monday, 29 September 2003 11:30:09 UTC