Subject: RE: Should ebXML standards be based on XML?
While HTTP is clearly the most ubiquitous protocol for moving XML, let's not lose sight of SMTP. As a secondary protocol it has a couple of advantages. a) inherent store and forward capability, removes the requirement for 100% up time of the receiver b) a specific addressing model below the domain name. At 4/14/00 09:46 AM-0500, Nieman, Scott wrote: >ebXML is not going to change the infrastructure of the Internet. Supporting >the MIME approach enables use over http, the most dominant B2B protocol of >the Internet. While there is a discussion to look at recasting http into >XML-based version, that would be a monsterously large undertaking >considering the number of web sites out there. > >The min requirement in my view is that the ebXML transport be recognized as >a valid MIME type by the IEFT, much like the intent of the SOAP submission >to IEFT. (Rik, please clarify if I am off base). > >In addition, it should be recognized that not all of the ebXML standards >will be purely XML based. The Business Process project team appears to be >recommending UML to describe business processes, which could easily be >recast into XML syntax for software consumption and rendered back into UML >for visualization. > >We must use the best-of-breed techniques that are in wide spread use today >instead of reinventing the wheel. > >Regards, > >Scott > >-----Original Message----- >From: Kit (Christopher) Lueder [mailto:firstname.lastname@example.org] >Sent: Friday, April 14, 2000 7:39 AM >To: ebxml >Cc: ebxml-requirements >Subject: Should ebXML standards be based on XML? > > >There is an active debate currently going on at the ebXML >Transport/Routing/Packaging list about whether the ebXML standards >should be based on XML. The current direction of that group is to use >MIME for the outer envelope, not XML. They are proceeding with a >specification that will be brought forward for vote, but that seems like >a pretty late time to ask for a change in direction, if you disagree >with their approach. If you have any concerns, this may be an opportune >time to express them. >Kit Lueder. >MITRE. > >-- > _/ _/ Kit C. J. Lueder > _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 > _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 > _/ _/ _/ _/ Mailstop W722 FAX: 703-883-7996 >_/ _/ _/ _/ McLean, VA 22102 Mail: email@example.com >Worse than an unanswered question is an unquestioned answer. > > >Subject: Concern with basic ebXML TRP Syntax/Semantics] > Date: Thu, 13 Apr 2000 18:16:51 -0700 > From: Nicholas Kassem <Nick.Kassem@eng.sun.com> > To: "Kit (Christopher) Lueder" <firstname.lastname@example.org>, Rik Drummond ><email@example.com> > CC: ebXML-Transport@lists.oasis-open.org > >Kit, >With all due respect I simply don't accept your literal interpretation >of >the recently published requirements document. We are clearly here to >move >XML into the business mainstream. I don't believe we have an option to >casually invent stuff on the fly when there are widely accepted and >credible Internet Standards out there nor can we ignore existing >business >imperatives. Waiting for an XML packaging scheme sanctioned by w3c is >not >an option, aligning with such a standard if/when it arrives is an >option. >We have repeatedly stated that this is our goal. Clearly, we are not >making >progress on this topic in this working group. So, perhaps the time/place >to >deal with this is when the requirements document comes up for an ebXML >wide >vote. > >My recommendation is that we inject some clarifying language in the >requirements document to enable pragmatic interpretation of that >document. > >Regards, >Nick > >At 11:45 AM 4/13/2000 -0400, Kit (Christopher) Lueder wrote: > >No. Maybe the Requirements group collects requirements from all the > >individual groups, but if there is a conflict in the requirements > >between different groups, the Requirements group (or as a last resort, > >the full ebXML) is the place to resolve them. > >Kit. > > > >Rik Drummond wrote: > > > > > > the requirements roll up from the teams to the requirements group... > > not the > > > other way around.... rik > > > > > > -----Original Message----- > > > From: firstname.lastname@example.org > > > [mailto:email@example.com]On Behalf Of Dick > > > Brooks > > > Sent: Tuesday, April 11, 2000 9:50 AM > > > To: Kit (Christopher) Lueder > > > Cc: ebXML-Transport@lists.oasis-open.org; Dick Brooks > > > Subject: RE: [Fwd: Re: Concern with basic ebXML TRP Syntax/Semantics] > > > > > > Kit, > > > > > > I agree with you, the issues with ebXML requirements need to be >addressed > > > and I believe Rik is aware of this. > > > > > > You referenced BizTalk as a pure XML packaging standard, but as far as I > > > know BizTalk is a Microsoft initiative and the spec is not being >developed > > > under a formal standards body (e.g. IETF, W3C). Besides, as far as I'm > > > aware, BizTalk does not define how to package PGP or S/MIME > > signed/encrypted > > > payloads in XML, which is one of the ebXML TRP requirements. > > > > > > Your question regarding a web server or browsers ability to generate a >MIME > > > envelope; actually MIME is the enveloping standard used in HTTP message > > > exchanges. All web forms are packaged in MIME envelopes, all server > > > responses are also, the bottom line is: MIME capability is an inherent >part > > > of web browsers/servers. In fact, the current ebXML packaging design is > > > compatible with several transports (SMTP, HTTP, HTTPS, FTP). > > > > > > Dick Brooks > > > http://www.8760.com/ > > > > > > -----Original Message----- > > > From: Kit (Christopher) Lueder [mailto:firstname.lastname@example.org] > > > Sent: Tuesday, April 11, 2000 7:45 AM > > > To: Dick Brooks > > > Cc: ebXML-Transport@lists.oasis-open.org > > > Subject: Re: [Fwd: Re: Concern with basic ebXML TRP Syntax/Semantics] > > > > > > Let's not get too defensive here...I raised the issue of MIME not being > > > a W3C standard a month ago, and when I saw that the group had proceeded > > > with a different design despite that issue, I raised the issue again. If > > > you think the issue was wrong, you should have escallated it to the > > > ebXML Requirements group where it originated, rather than ignoring it. > > > > > > I don't see why "There is no XML based standard for packaging mixed > > > payloads" means you must go with a MIME solution rather than creating an > > > XML packaging standard? Also, I thought BizTalk was a pure XML packaging > > > standard, so this statement wasn't really true? > > > > > > Regarding "MIME is not that difficult to process", how hard is it for a > > > web server to generate MIME envelopes along with the XML content after > > > the user has filled in a web form (or what ever method for triggering > > > the generation of XML content)? (This is a serious question, not a > > > criticism...) > > > > > > Sincerely, > > > Kit. > > > > > > Dick Brooks wrote: > > > > The packaging sub-group has spent several weeks coming up with this > > design > > > > and now it seems some people want to "unravel" it and start all over > > > again. > > > > If we keep revisiting and rehashing decisions we will not meet our > > > > deadlines. > > > > > > > > The packaging sub-group discussed one container versus two and the > > reasons > > > > we decided on two containers follow: > > > > > > > > - One XML container means that the entire document (which could be > > > GIGABYTES > > > > of data) would have to be processed/parsed as a single XML document. >This > > > > would make processing time slow and could seriously impact response >time. > > > > > > > > - There is no XML based standard for packaging mixed payloads. The >ebXML > > > > group would have to create a XML based packaging standard and this >didn't > > > > seem practical when we could very easily apply MIME to a task it was >well > > > > designed to handle. this also met the group requirement to use >existing > > > > solutions whenever possible (don't re-invent the wheel). > > > > > > > > - There is a large installed base of products that support MIME and > > > > developers who are familiar with MIME. Scott, MIME is not that > > "difficult" > > > > to process - I'll bet I could teach you how to process the ebXML MIME > > > > envelope in less than two hours using MIME++, assuming you're familiar > > > with > > > > C++ ;^). > > > > > > > > I assert that a MIME solution using two "containers", is superior to a > > > > single XML container for for the following reasons: > > > > - there are no illeagal characters to deal with in MIME as >there > > > are in XML > > > > (& < all have to be transformed) > > > > - there are mature, proven packages available to parse MIME, >an > > > XML > > > > solution would have to be developed > > > > - binary objects are transportable without any conversion with > > > MIME (no > > > > base64 needed when using HTTP transport); > > > > with XML binary objects must be base64 encoded > > > > - applying base64 to a payload adds appx 40% to its size and >this > > > adds time > > > > to transmit and process. > > > > - There are already MIME based STANDARDS for packaging a > > > significant body > > > > of objects (jpeg, EDI, XML, html, et al), these would all have to be > > > created > > > > for an XML based packaging solution. > > > > > > > > Some people have suggested using the existing MIME headers and media > > types > > > > to create an XML packaging specifcation, then we could have MIME in >XML. > > > > Why - what is the benefit of this - the ability to say we have a pure >XML > > > > packaging solution? > > > > > > > > The packaging sub-group is certainly open to a better solution - if >one > > > > exists. Please announce to the list any STANDARD based XML packaging > > > > solutions that we should consider, please be sure to include how the > > > issues > > > > above are addressed. > > > > > > > > Thank you, > > > > > > > > Dick Brooks > > > > http://www.8760.com/ ---------- Wes Rishel Research Director Healthcare Industry Research & Advisory Services GartnerGroup Alameda, CA email@example.com (for general correspondence) firstname.lastname@example.org (for GG business) http://www.rishel.com 510 522 8135 ----- This message does not represent an opinion of The GartnerGroup, or any other organization.
Powered by eList eXpress LLC