Use of MTOM in other problem domains

I have an open AI to find out more about a MTOM-like technology that I 
overheard discussion about at the Binary XML Workshop.

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

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.

If this is the case, it would be good to avoid duplication of effort 
and leverage implementations so that many different applications can 
reuse the infrastructure; after all, this is what XML is all about. As 
such, 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.

Thoughts?

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Friday, 10 October 2003 19:17:55 UTC