[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: mime vs xml header
I think we can usefully come up with a set of "requirements" just for the outer wrapper, for example: 1. Handling arbitrarily large documents 2. Wrapping any type of content without having to transform it (e.g. by changing "<" into "<", or doing Base 64 encoding) 3. Processing the outer wrapper safely when there are errors in the inner document. Is there anything else. My current view is that MIME handles all these things nicely but XML doesn't so easily (can anyone shed a light on this?) That way we can: 1. Have a rational basis for our decision 2. Provide input into groups working on an XML wrapper, e.g. the W3C Thoughts? David -----Original Message----- From: Kit (Christopher) Lueder [mailto:firstname.lastname@example.org] Sent: Wednesday, March 15, 2000 7:52 AM To: ebxml-transport Subject: mime vs xml header > Dick Brooks wrote: > I don't recall the name of the person assigned to produce the document, it > may have been Kit Lauder. Hi Dick, I agreed to coordinate discussion on the MIME vs XML header question. I don't think there was a particular document planned for that, aside from our regular deliverables. Anyway, let's try to wrap up the MIME vs XML header issue tomorrow's teleconference, if we can. I think we should be prepared for a vote for your preference, MIME-based envelope, XML-based envelope, or both. Kit. To recap: On Thursday, 3/9, I posted a message giving a high-level summary of the two enveloping approaches: mime envelope (from Dick/Nick's paper) and pure XML envelope. > Mark Crawford wrote (lots of questions, few answers), Friday 3/10: > It appears to me that one of the things missing in the mime vs. XML debate is > what are the XML server developers and XML business standards bodies doing. At > the Orlando meeting, Rik indicated the transport group was going to look at > different enveloping solutions, including RosettaNet and BizTalk. Did that > happen? If so, what were the results? (yes I know RosettaNet uses Mime and > BizTalk supports Mime for binary data, but does that mean we adopt Mime as "the" > solution?). By the same token, are there representatives in the transport group > from such companies as - webMethods, Bluestone, Microsoft, Sun, IBM and others > involved in developing industrial strength XML servers? ... On Saturday 3/11, David Burdett responded to Dale Moberg regarding using XML or MIME to wrap arbitrary content. On Monday 3/13, Dale Moberg posted an elaboration (Almost-everywhere XML Packaging for ebXML: strawman for discussion) of my XML proposal, showing tags for <XMLPackage> and other MIME-like attributes. Here is a revised version of my (Kit's) list of benefits of both approaches, after trying to capture the discussion of the last week: Benefits of MIME envelope: - If you are using e-mail, it falls out automatically. The design proposed by Dick & Nick is intended to be the same as what is supported by browsers now. - If you want to parse the header but don't want to parse the body (content), some XML parsers aren't able to arbitrarily stop in the middle of a document. (e.g., if you have an ebXML envelope around a huge document content and don't want the overhead of parsing the whole thing.) MIME allows the header to be a separate attachment from the body, so they can be parsed separately. - If you have an XML parsing error anywhere in the document, the parser fails. Thus an error in the content will kill parsing of the envelope, if it is all XML. The MIME processor can be tolerant of errors in the MIME envelope (e.g., ignore unrecognized tags). - MIME can still handle the attachment even if the content-body is not based on XML, e.g., to support a binary attachment. - Having the attachment separate from the header within the MIME message allows the attachment to be compressed or encrypted without concealing the headers. Benefits of pure XML solution (no MIME envelope): - It is a pure XML solution, which meets the possible "ebXML requirement" of our solution being W3C-compliant. Only one technology is used for it. - Publishing a pure XML solution merely involves creating an XML schema on a repository. - You don't have to do special processing to strip the MIME envelope before feeding the XML stuff to the XML parser. - If you have a web server and a user fills out and submits a web form, I suspect it is easier for the server back end to generate pure XML, rather than having to generate a MIME envelope as well. - Some event-based parsers and maybe SAX parsers could support parsing just the envelope (per Matthew MacKenzie). You might need to know in advance that it is an ebXL envelope, though (per David Burdett), such as with a transport parameter such as: message-type: ebXML. Aspects that are applicable to both approaches (per Prasad Yendluri <email@example.com>): - The ability to pack together varying number of, disparate content types(xml and non-xml including binary forms), without having to resort to special conversion / data encoding schemes (e.g. binary to UUENCODE). - To keep business content independent of and disjoint from routing information so that, entities performing the routing (potentially third parties), don't need to (or should not) look into the business message. - Facilitate detection and reporting of errors back to the originating party (by the receiving party), even if the business content is not something handled by the receiving party. That is, have a well defined standard header and variable business content, that are packed together. -- _/ _/ Kit C. J. Lueder _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 _/ _/ _/ _/ Mailstop W658 FAX: 703-883-3383 _/ _/ _/ _/ McLean, VA 22102 Mail: firstname.lastname@example.org Worse than an unanswered question is an unquestioned answer.
Powered by eList eXpress LLC