Re: generic MTOM proposal

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