Re: Use of MTOM in other problem domains

Hi Robin,

	Sorry didn't see this earlier.  If you want to post the contents
of my message somewhere publicly, feel free to do so.  I'm not sure
where you'd want to post it, but I have no problem with that.

Alex

-- Original Message from Robin Berjon--
Mark Nottingham wrote:
> I have an open AI to find out more about a MTOM-like technology that I 
> overheard discussion about at the Binary XML Workshop.

Off the top of my head, the participants that stressed packaging issues most 
were Canon, Adobe, Expway, and CCSDS (a working group composed of several space 
agencies, NASA, ESA, etc). I'm sure I'm forgetting a few, since binary payloads 
seemed to be something most of the participants were interested in.

In addition to that, it appears to me that one of the points most participants 
agreed upon was that whatever a binfoset format could do should also be doable 
at the XML level. Making MTOM generally available naturally means that this will 
be one step easier if anything happens in the binfosets area.

> I'm still trying to find the reference, but as I was digging, this 
> appeared:
>    http://lists.w3.org/Archives/Member/w3c-svg-wg/2003JanMar/0711.html

While I can't talk for the SVG WG, I believe that this document represents at 
least a vague consensus on what is required. Note that since it is a member-only 
document, and seems to get referrenced publicly here and there, maybe Alex 
(Cc'd) should put it at a more public location (or allow us to)?

> It seems that SVG has *many* similar requirements, and I've had SVG 
> folks tell me that they'd love to explore this in conjunction with XMLP. 
> Based on discussions I've had with others, I'm led to believe that there 
> are a number of other formats that would benefit from a 
> generically-defined MTOM mechanism.

I wholeheartedly agree.

> it seems like there are three options open to us;
> 
> 1. Continue working on a SOAP-only MTOM.
> This is what we're doing today.
> 
> 2. Contribute to an externally-specified MTOM-like facility and use it 
> for SOAP.
> This is the path we considered in the discussion of 
> XInclude-with-a-base64-twist. People seem to be wary of this, perhaps 
> because of schedule concerns and/or our ability to assure that the 
> outcome is suitable.
> 
> 3. Continue working on MTOM as a generic format that's separable from SOAP.
> I don't think it would require too much work to get here. Specifically, 
> I think we'd need to:
>    a. assure that the format identifies the post-processed media type of 
> its content (e.g., in our case, application/soap+xml) so that it were 
> generic
>    b. separate the MTOM format specification out so that it is 
> independent of SOAP.

I guess that (3) could be understood as "XMLP continues to work on this, but 
requires regular and in-depth review by other WGs, more notably the SVG WG, so 
as to ensure that other grammars can reuse MTOM without incurring dependencies 
on SOAP". If timing issues are critical to some, then I suspect that would be a 
viable option. Otherwise, I would have a preference for (2) as it seems to more 
readily reuse existing W3C infrastructure.

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Scientist, Expway      http://expway.com/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Received on Monday, 24 November 2003 22:24:36 UTC