W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2003

Sharing MTOM parts for identical leaf nodes

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 26 Sep 2003 20:31:25 -0400
To: xml-dist-app@w3.org
Message-ID: <OFAE3F6D3C.D4F961BD-ON85256DAE.00026A81@lotus.com>





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 Sunday, 28 September 2003 13:03:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT