- From: John J. Barton <John_Barton@hpl.hp.com>
- Date: Wed, 05 Nov 2003 10:28:50 -0800
- 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. > >Rationale: > >Allowing MIME parts that are unreferenced breaks the infoset model. >Ensuring MIME parts are referenced exactly once simplifies >implementations. > >Cheers > >Gudge > >[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440 ______________________________________________________ John J. Barton email: John_Barton@hpl.hp.com http://www.hpl.hp.com/personal/John_Barton/index.htm 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