RE: Should ebXML standards be based on XML?

[Wes Rishel <wes@rishel.com>]

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:kit@mitre.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: kit@mitre.org
>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" <kit@mitre.org>, Rik Drummond
><drummond@onramp.net>
>        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: owner-ebxml-transport@lists.oasis-open.org
> > > [mailto:owner-ebxml-transport@lists.oasis-open.org]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[2]: 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:kit@mitre.org]
> > > Sent: Tuesday, April 11, 2000 7:45 AM
> > > To: Dick Brooks
> > > Cc: ebXML-Transport@lists.oasis-open.org
> > > Subject: Re: [Fwd: Re[2]: 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
> > > > (&amp &lt 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
wes@rishel.com (for general correspondence)
wes.rishel@gartner.com (for GG business)
http://www.rishel.com
510 522 8135
-----
This message does not represent an opinion of The GartnerGroup, or any 
other organization.