Re: Should ebXML standards be based on XML?

["Klaus-Dieter Naujok" <klaus@templar.net>]

Instead of me voicing my view on this topic raised by Kit, let
me quote Jon Bosak's message he sent out during this discussion
in the Transport PT, since his comments are full of common
sense.  I also like to underline the point raised by Scott's
reply:

"We must use the best-of-breed techniques that are in wide
spread use today instead of reinventing the wheel".  This view
has been expressed by the Executives since the start of ebXML
and is still valid today and for the rest of this initiative.

I hope with those comments that we can move on in order to
receive the Draft Specification from the Transport Team shortly
in order to evaluate the technical solution on its technical
merits.

Regards,

Klaus-Dieter Naujok
ebXML Chair

PS. Please forgive me for sending this to multiple lists, but
currently ebXML's general list does not cover all ebXML
participants. Because of it, I am posting to those lists that
Kit posted on.

==========================================================

Date: Mon, 10 Apr 2000 22:53:39 -0700 (PDT)
From: Jon Bosak <bosak@boethius.eng.sun.com>
Subject: Re: Concern with basic ebXML TRP Syntax/Semantics]
Sender: owner-ebxml-transport@lists.oasis-open.org

Using mime wrappers for XML documents in order to build upon
existing technology seems like such an obvious idea that I feel
that I must be missing something.  If it's in place and it can
do the job of schlepping XML messages around, why not?

There must be more here than meets the eye or you guys wouldn't
be arguing about it, but I can't see what it is.

If some part of the mime package can contain a complete XML
document, and if in the future a standard is created for
packaging that instantiates a package as an XML document, then
that package can be included in the mime wrapper...  Right?

If you wait for someone else to define an XML packaging
mechanism, you will be waiting a long time.  The last attempt to
define a standard transport packaging mechanism for XML/SGML was
five years ago, and it fell apart because multipart/related
wasn't ready yet.

Jon