Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]

[Jon Bosak <bosak@boethius.eng.sun.com>]

[Nick Kassem:]

| I believe we have agreed to support:
| 
| 1) Pure XML for Message Headers
| 2) Pure XML for payloads
| 3) *optionally* non-XML payloads (because there is a large non-XML legacy).
| 
| The fact that the current packaging proposal recommends using
| multipart-related to bind the elements into a single message is
| simply pragmatic. IMO. We are proposing to use an existing
| Internet standard. No application will ever have to see the outer
| wrapper (be it in MIME or whatever) - in the same way that one
| normally doesn't see TCP headers or "200 OK" from HTTP. Most
| importantly applications will see pure XML if that's in the
| message payload. If this approach offends the sensibilities of
| some then we should go out of our way to solicit counter proposals
| - and review them openly.
| 
| Jon, are we completely off-track here ?

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