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

Re: Proposed resolution for issue 440

From: John J. Barton <John_Barton@hpl.hp.com>
Date: Wed, 05 Nov 2003 10:28:50 -0800
Message-Id: <>
To: "Martin Gudgin" <mgudgin@microsoft.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>

In my opinion allowing duplicated includes to reference the same MIME part
would simplify implementations, not make them more complex.  Do you really
want to explain over and over again that even though MTOM uses the
word "include" it does not act like any include mechanism familiar to
programmers? Even though the URI mechanism is used to ref the content,
you must have unique URIs for each MIME ref?  Etc: it just seems silly.

To put this in use-case terms, consider a multipage UI carried in a message,
each page consisting of the same large template image combined with a bit of
unique text.  Why force the template to be sent multiple times?

Or am I misunderstanding: is there another layer of indirection here?

Disallowing un-referenced MIME parts seems like a good choice.

At 09:48 AM 11/5/2003 -0800, Martin Gudgin wrote:

>On the call today we discussed issue 440[1] which asks
>1.      whether MTOM packages can contain MIME body parts that are NOT
>referenced by an xbinc:Include element
>2.      whether a MIME body oart can be referenced by multiple
>xbinc:Include elements
>I took an action to propose a resolution to this issue, so here it is.
>Proposed resolution:
>Each MIME body part (except the root) MUST be referenced by exactly one
>xbinc:Include element. Intermediaries are required to respect this rule.
>Allowing MIME parts that are unreferenced breaks the infoset model.
>Ensuring MIME parts are referenced exactly once simplifies
>[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440

John J. Barton          email:  John_Barton@hpl.hp.com
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100
Received on Wednesday, 5 November 2003 13:28:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:24 UTC