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

Re: Proposed resolution for issue 440

From: Herve Ruellan <herve.ruellan@crf.canon.fr>
Date: Thu, 06 Nov 2003 10:05:46 +0100
Message-ID: <3FAA0EEA.4070009@crf.canon.fr>
To: "John J. Barton" <John_Barton@hpl.hp.com>
Cc: Martin Gudgin <mgudgin@microsoft.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>

John,

See my comment below.

John J. Barton wrote:

> 
<snip/>
> 
> 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?

Yes, to prevent the transmission of the template multiple times, you can 
add another layer of indirection in the XML message. In this way, each 
UI page would refer to an XML element which would contains the large 
template image.

In its current state, MTOM only does *some* optimization for message 
transmission, mainly by transmitting base64 encoded data directly in binary.
It could be argued that MTOM could do more optimization such as checking 
that it sends the same base64 encoded data only once.
However, I think it is better to do this optimization at a higher level: 
in your use case, the creator of the multipage UI knows that the 
template image is the same for each page, therefore, the creator should 
take some steps to insure that this template image is include only once 
  in the XML document. This has several advantages:
- The creator of the XML document will probably have efficient way of 
knowing that two template images are identicals, while the MTOM level 
will probably have to compare those images bit by bit.
- The creator of the XML document may not know in advance that this 
document will be transmitted by a "special MTOM" able to detect and 
optimize duplicate binary data.

Best regards,

Hervé.
Received on Thursday, 6 November 2003 04:06:52 GMT

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