[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Re[2]: MIME vs pure XML ebXML structure
Mark, I think this excerpt from your first sentence says it all; "I need to know that the solution meets all of my clients needs". It would be truly beneficial to see some real customer requirements to help us in this effort. I, like others in the group (yourself included), work with numerous parties that are currently or will be doing E-commerce. ALL of the parties I work with (mostly Energy and Healthcare companies) are using X12 as their transfer syntax, and candidly they are wondering what the benefits will be in moving to XML. There's still a lot of XML "tire kicking" going on. Clearly, these are not XML purists I'm talking about, but they are doing E-Commerce and they intend to do more of it. They are using the "transport" facilities available to them, mostly HTTP and E-mail to transport their transactions. For the most part they are pleased with the results. This group of early adopters are an important group. They have investments and strategies in E-Commerce and we need their support if ebXML is ever going to succeed. I believe we risk losing their respect if we produce a XML only packaging scheme that isn't usable with existing transport facilities, or that requires special treatment to make it work over E-mail or HTTP. Especially since they KNOW its possible to send XML via E-mail and HTTP today using existing infrastructure. In summary, I firmly believe we should follow our guiding principles and not "RE-INVENT THE WHEEL"; if something meets our needs, lets use it. Dick Brooks http://www.8760.com/ -----Original Message----- From: owner-ebxml-transport@lists.oasis-open.org [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Mark CRAWFORD Sent: Friday, March 10, 2000 6:23 AM To: ebxml-transport@lists.oasis-open.org Subject: Re[2]: MIME vs pure XML ebXML structure Greetings, If I am going to elicit ebXML support from my client base, then I need to know that the solution meets all of my clients needs. That has been the basis of my concern regarding Mime and the posibility that it was going to be "the" ebXML solution. 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? (I talked to an engineer at webMethods the other day - they support both but can't really see a need for Mime except for binary data). What about the low-end servers that the SME's may buy into? If such contacts have been made, what do they say about providing both XML and Mime solutions? If not, what has the transport group done to canvas those folks regarding their proposed solution? Mark Mark Crawford Research Fellow ______ LMI Logistics Management Institute 2000 Corporate Ridge, McLean, VA 22102-7805 (703) 917-7177 Fax (703) 917-7518 mcrawfor@lmi.org http://www.lmi.org "Opportunity is what you make of it" ____________________Reply Separator____________________ Subject: Re: MIME vs pure XML ebXML structure Author: "Kit (Christopher) Lueder" <kit@mitre.org> Date: 3/9/00 3:23 PM Hi, Someone on the list asked me the benefits of the two approaches. I figured I would answer to the whole list. Here is a quick stab at it. Any other points I left off? Kit. Benefits of MIME envelope: - If you are using e-mail, it falls out automatically. - If you want to parse the header but don't want to parse the body (content), 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. 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. - 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. So I don't lean one way strongly over the other way. Both sides have their benefits. Kit. > Hey Kit, > Can you explain what some of the perceived benifits to using > MIME (say .vs. something like the all xml example you layed out)? -- _/ _/ 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: kit@mitre.org Worse than an unanswered question is an unquestioned answer.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC