- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Tue, 18 Nov 2003 14:48:08 +0900
- To: Mark Nottingham <mark.nottingham@bea.com>
- Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Hi Mark, Mark Nottingham wrote: > Please find attached a rough proposal for a generic MTOM specification. > I apologise again for its lateness. Having been busy I may have missed a few things, but here are a few notes on Miffy. Overall, I like it a lot (including the name :). - why only base64Binary and not hexBinary (not that I mind but the document should state why) - 2.1 seems to open the door to recommending a mime type for the root MIME part. Is this with the intention of having a single application/miffy MIME type for all MIFFY roots? I think that that would lose important information for non-obvious (to me) gain. If so, why not use a MIME header instead, eg Miffy-Version? Other than that, one may wish to restrict that to application/xml, text/xml, and anything that ends in +xml but I have doubts as to what that gains taking into account the fact that some MIME types out there may exist without falling into those three boxes. Notably, XHTML can (unfortunately) be used with the text/html MIME type, not just application/xhtml+xml. But then I may be reading a lot into a TBD :) - in addition to requiring that mime:content-type match Content-Type you may wish to encourage using only one of those to avoid desynchronisation when processing is interupted unexpectedly, or race-conditions for trees that may be accessed by multiple threads in parallel. - I believe that there are two things missing from this proposal to extend it fully beyond the SOAP world: support for attributes, and a replacement for data: URIs. Attributes could be done by: 1) removing them from their owner element; 2) creating an xbinc:AttributeInclude child with the same pointers to optimised information (or the same element using step 3 to know that it corresponds to attribute content); 3) give it an original-name attribute holding a QName (following attribute namespace rules naturally, ie it's *not* an xs:QName) being the name of the attribute; 4) prepend that child to the children of that element. It is possible that the MIME type would not be known, in which case it would be application/octet-stream. data: URIs could be considered to occur only in attribute values (which is probably true in practice, at least I know of no other usage). As such, they would be optimised in a way similar to that in which attributes are, with the added benefit that they carry their MIME types and would have a flag indicating that they were a data: URI. The latter would allow SVG to use Miffy directly to great benefit as data: URIs represent most of its embedding of binary resources. I believe that the same goes for XHTML. Cheers, -- Robin Berjon
Received on Tuesday, 18 November 2003 00:51:53 UTC