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

["James McCarthy" <jamesm@webxi.com>]

David,

I have been trying to drive that suggestion into this groups discussion for
over a month now. I completely agree with your approach. It simplifies the
case where only XML content is required. I have felt that we have spent way
too much time discussing non-XML content when 80%-90% of the time the
content will be pure XML.

You could even go so far as to only require MIME wrapping if non-XML content
is required. Therefore, a receiving application would simply have to first
check for the MIME content type header and parse it as specified. If it does
not exist then it can look for text/xml content type header. If it is type
text/xml this stream can be read directly into an XML parser.

If the group wants to always assume there will be a MIME outer wrapper that
would be OK too but I would encourage the ability to skip MIME altogether
since MIME is foreign to some transport types and hinder adoption of the
ebXML headers as a standard.

Jim McCarthy
WebXi, Inc.
http://www.webxi.com/


> -----Original Message-----
> From: owner-ebxml-transport@lists.oasis-open.org
> [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of David
> Burdett
> Sent: Monday, April 10, 2000 2:38 PM
> To: 'dick@8760.com'; Jon Bosak; ebXML-Transport@lists.oasis-open.org;
> Nicholas Kassem
> Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
>
>
> Now this may be off the wall somewhat, but there might be a way
> that we can
> provide support for BOTH XML and MIME. The basic idea is described in the
> following structure that just *might* work. What you would have is:
>
> 1. A MIME outer wrapper that contains:
>    a) an initial MIME part that contains:
>       i) a single XML document that contains:
>         * a mandatory Message Header element that contains
>           several header parts as are being developed/
>           discused on this list
>         * zero or more body parts that each consist of XML payloads,
>           where each payload has a single XML element that has a
>           separate XML namespace
>    b) zero or more additional MIME parts that can contain
>       anything that is *not* XML
>
> This way, if you only needed XML, then you would have no additional MIME
> parts. On the other hand if you did need non-XML documents then you could
> use separate MIME parts to hold it.
>
> This also resolves the real problem with XML in that you can't put XML
> inside XML without, either base64 encoding it (CDATA doesn't work
> since you
> can't put CDATA inside CDATA).
>
> Thoughts?
>
> David
>
>
>
> -----Original Message-----
> From: dick@8760.com [mailto:dick@8760.com]
> Sent: Saturday, April 08, 2000 8:53 AM
> To: Jon Bosak; ebXML-Transport@lists.oasis-open.org; Nicholas Kassem
> Cc: dick@8760.com
> Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
>
>
> The packaging group investigated every "lead" in the search for a pure XML
> packaging solution. I asked David Turner from Microsoft if they had a pure
> XML
> packaging solution, he never responded.  Some other proposals looked
> promising
> (XMTP, for example), but none were on a standards track with any standards
> making body.
>
> Nick is 100% on the mark. The ebXML packaging specification DOES support
> pure
> XML payloads, as well as other non-XML payloads. The reason we
> chose MIME to
> encapsulate the ebXML header (which is pure XML) and Payload (be it XML,
> EDI,
> JPEG, text, et al)  is because we could not find a STANDARDS TRACK  "pure
> XML"
> packaging solution that provided the capabilities of MIME.
>
> The bottom line is, MIME is the ONLY standard packaging
> technology available
> that meets the ebXML requirements for Transport, Routing and Packaging.
> However,
> the packaging group does recognize that a XML based packaging
> standard could
> emerge and for this reason the specification will "leave open" the
> possibilities
> of a pure XML packaging solution becoming part of the specification in the
> future.
>
> Dick Brooks
> http://www.8760.com/
>
>
>
> ----- Original Message -----
> From: Nicholas Kassem <Nick.Kassem@eng.sun.com>
> To: Jon Bosak <Jon.Bosak@eng.sun.com>;
> <ebXML-Transport@lists.oasis-open.org>
> Sent: Friday, April 07, 2000 10:01 PM
> Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
>
>
> > 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 ?
> >
> > Regards,
> > Nick
> >
> >
> > At 01:30 PM 4/7/2000 -0400, Christopher Ferris wrote:
> >
> >
> > >-------- Original Message --------
> > >Subject: Re[2]: Concern with basic ebXML TRP Syntax/Semantics
> > >Date: Fri, 07 Apr 2000 11:56:39 -0400
> > >From: "Mark CRAWFORD"<mcrawfor@lmi.org>
> > >To: <chris.ferris@East.Sun.COM>
> > >CC: <ebXML-Requirements@lists.oasis-open.org>
> > >
> > >Chris,
> > >
> > >     I think we will have to agree to disagree.  My argument all along
> > >has been
> > >that we are about XML, not using the guise of ebXML for individuals to
> > >resurrect
> > >their pet technology standards projects of the last several years. (and
> > >I am not
> > >just talking about TRP, but some of the other efforts within ebXML as
> > >well).  If
> > >webMethods can exchange information using XML wrappers, and if BizTalk
> > >can
> > >exchange information using XML wrappers (yes I know they use mime to
> > >encapsulate
> > >binary objects within the XML document instance), then why can't we?
> > >And oh by
> > >the way, if MIME is the answer and simple e-mail attachments are the
> > >best
> > >solution, explain to me how come people still have serious email and
> > >attachment
> > >interoperability problems? Also, if we are going to use MIME
> as the only
> > >ebXML
> > >solution, which MIME RFC are we going to use?
> > >
> > >     At a more basic level, there is a philosophy issue that I
> am afraid
> > >is being
> > >overlooked.  In the ISO and IETF world, there is a lot of good
> standards
> > >work
> > >that goes on by some very smart people, but in many cases that work is
> > >just for
> > >the sake of building standards without regard to who really wants them.
> > >My
> > >clients really could care less about ebXML if it is just rehashing IETF
> > >MIME or
> > >OO technology, or Open EDI, or Business Message Modeling, or X12 SITG
> > >registry
> > >and repository, or any of the other hidden agenda's that I see moving
> > >behind the
> > >scenes of ebXML.  I can only sell ebXML as a solution if it
> provides XML
> > >based
> > >standards for exchange - and more importantly - content. We are not
> > >headed in
> > >that direction, and I am under increasing pressure to just go implement
> > >CommerceOne or webMethods and stop the XML "standards" push.  Despite
> > >all the
> > >ebXML stuff about creating an interoperable technical framework, the
> > >real
> > >interest being expressed by my clients is in standardizing the content,
> > >not the
> > >wrapper so they know what data elements they need to support in their
> > >databases
> > >and applications (databases and applications that will not be moving to
> > >an OO
> > >environment for years and years).
> > >
> > >     If TRP believes that XML technology does not support all of
> > >requirements for
> > >interchange they have addressed, then I believe this is an
> issue for the
> > >entire
> > >ebXML plenary not just TRP.  There are a number of alternatives open -
> > >
> > >     1) Provide XML solutions for those requirements that can be
> > >addressed
> > >(reduce requirements)
> > >     2) Provide dual path XML and MIME solutions
> > >     3) Provide a MIME solution and publically state that we are not
> > >developing
> > >XML based solutions, but another MIME standard for exchanging XML
> > >content
> > >because the technology is too immature to support B2B data exchanges.
> > >
> > >     .
> > >     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"
> > >
> > >-------------------------------------------------
> > >Chris Ferris Wrote -
> > >
> > >Mark,
> > >
> > >Not at all! Again, I think that the issue is getting overblown.
> > >The MIME wrapper is merely a means of packaging
> > >XML documents (header information and payload) which
> > >can be:
> > >     - parsed separately so that for routing purposes, the
> > >     entire message need not be parsed
> > >     - separately signed (there might be a different certificate
> > >     applied to the header than to the payload)
> > >     - include non-XML content such as medical images (JPEG, MPEG)
> > >
> > >and more. The MIME use is simply a mechanism which existing
> > >technology can handle, enabling SME's to jump right in without
> > >having to expend significant resources. There does not yet exist
> > >a W3C XML packaging specification to achieve these aims.
> > >Our intent is to submit these requirements to the W3C so that
> > >they are considered in any packaging work and ultimately so that
> > >the ebXML packaging approach can be migrated (in a later
> > >release) to such technology.
> > >
> > >Chris
> > >-------------------------------------
> > >Mark CRAWFORD wrote:
> > >
> > > > Chris,
> > > >
> > > >     Perhaps we should just change our name to ebMime since TRP
> > > considers XML
> > >too immature or hard.
> > > >
> > > >     Mark
> > > > Mark Crawford
> > > > Research Fellow
> > >
> > >---------------------------------------------------------
> > >Chris Ferris Wrote -
> > >
> > >Kit,
> > >
> > >While I wasn't able to participate the the f2f meeting in
> > >Dallas and can't speak to the finalized packaging minutia
> > >I can address this from the perspective of one of the
> > >members of the packaging sub-team.
> > >
> > >We discussed this in depth in the packaging sub-team.
> > >We felt that there was inadequate support in the various
> > >W3C XML recommendations to support our requirements
> > >which follow:
> > >
> > >- Able to handle large documents
> > >- Able to envelope any document type
> > >- Minimize intrusion to payload (special encodings or alterations)
> > >- Minimize potential for abnormal termination caused by envelopes
> > >- Facilitate a migration path for existing installed base and
> > >technologies
> > >- Low processing overhead
> > >- Support for recursive documents
> > >- Able to preserve digital signatures
> > >- Able to unambiguously identify signed data
> > >
> > >To quote Dick's minutes of our sub-team meeting:
> > >
> > ><db>
> > >Both MIME and XML were discussed relative to these requirements. It
> > >was the groups consensus that MIME was better positioned today to
> > >meet the stated requirements. However, it was also believed that XML
> > >would mature as a packaging technology and the ebXML group should
> > >continue to monitor XML's progress for possible inclusion at a later
> > >date.
> > >It was also believed that Microsoft may have addressed some of the
> > >issues affecting XML's packaging ability. Dick Brooks accepted an
> > >action item to contact Microsoft to request information describing
> > >BizTalk's packaging functions to see if this may provide an XML
> > >packaging solution that meets the above requirements.
> > ></db>
> > >
> > >Another consideration in our work, and something clearly called out
> > >in the ebXML requirements document are the vision bullets.
> Specifically:
> > >     - is fully compliant with W3C XML technical
> specifications holding a
> > >         recommended status
> > >     - maximizes interoperability and efficiency while providing a
> > >         transition path from accredited electronic data interchange
> > >(EDI)
> > >         and developing XML business standards
> > >
> > >The first is key. It refers to W3C technical specifications holding
> > >a *recommended* status. The second is also key. It refers to
> > >a requirement to enable existing solutions such as RosettaNet and
> > >EDI/INT, etc. to interoperate (at least that's how I read it).
> > >This second bullet is called out again in the "General ebXML
> > >Principles" section in the Requirements document. Someone certainly
> > >thinks it s important. I for one concur.
> > >
> > >Another consideration which went into our thinking is the availability
> > >of software to handle the package. HTTP and SMTP clients and
> > >servers already support MIME and are both inexpensive and
> > >widely available if not ubiquitous.
> > >
> > >In the Requirements document, under the TR&P sub-section, #2
> > >     "Leveraging existing technology encompasses both the ability to
> > >     interoperate with existing technology as well as the ability to
> > >     migrate to the new technology".
> > >
> > >In fact, that whole section pretty much sums it up for me.
> > >
> > >I believe that there is consensus that ultimately, we will transition
> > >to an XML-based approach to packaging, but at least for the
> > >first go, MIME is the only solution which satisfies all of the
> > >requirements.
> > >
> > >To my knowledge, the ebXML Requirements document doesn't
> > >say "use XML to the exclusion of any other technology just because".
> > >MIME seems to meet our requirements and since the content
> > >of the MIME segments is XML (except in cases where an
> > >"attachment" is of some other type such as image, etc.) we're
> > >also meeting the spirit of the ebXML requirements.
> > >
> > >If you have knowledge of a purely XML-based packaging
> > >solution which meets all of the stated requirements, and which
> > >the packaging sub team has missed in its considerations, I'm
> > >sure that we'd be glad to reconsider.
> > >
> > >Cheers,
> > >
> > >Chris
> > >
> > >"Kit (Christopher) Lueder" wrote:
> > >
> > > > I have a concern with the basic ebXML TRP approach. As I indicated
> last
> > > > month, as far as I know, the TRP approach is in conflict with the
> ebXML
> > > > Requirements specification. If I understand right, the ebXML TRP
> > > > solution is MIME based only, which is not an XML solution.
> > > >
> > > > I quote the last paragraph from Section 1 Introduction of the ebXML
> > > > Requirements:
> > > > "A key aspect for the success of the ebXML initiative is
> adherence to
> > > > the use of the W3C suite of XML and related Web technical
> > > > specifications.  Although these specifications may not provide the
> > > > optimal technical solution, acceptance of ebXML by the business
> > > > community and technical community is tied to XML.  Alternative
> > > > technologies and technical specifications may be
> incorporated as part
> of
> > > > the ebXML solution.  However these alternative technologies and
> > > > specifications will only be provided as an alternative to
> the provided
> > > > XML solution unless the W3C XML and related Web technical
> specifications
> > > > can not accomplish the same business functionality."
> > > >
> > > > Kit.
> > > >
> > > > Todd Boyle wrote:
> > > > >
> > > > > I would appreciate any information or links regarding the
> duplicated
> > > > > or overlapping information in multiple layers of headers and
> wrappers.
> > > > > My understanding is that a typical ebXML message might contain
> > > > >
> > > > >   HTTP/MIME multipart/related header
> > > > >     ebXML header
> > > > >     payload1
> > > > >       Biztalk, or MSMQ/MQseries etc. header
> > > > >       Biztalk, or MSMQ/MQseries etc. header
> > > > >          Rosetta, OAG, CBL2, etc. document
> > > > >              Rosetta, OAG, CBL2, etc. required document header
> > > > >                  The XML message content which would usu. include
> > > > >                  all the parties' identities and reference codes
> > > > >     payload2
> > > > >     payload3   etc.
> > > > >
> > > > > No doubt I've got this screwed up someplace.  I imagine for the
> coming
> > > > > 12-24 months MOM or MQ servers will be required no matter
> what ebXML
> > > > > comes up with, and accordingly ebXML header and MOM headers will
> both
> > > > > be transported?
> > > > >
> > > > > My real question is, how to eliminate all duplication and
> if that is
> > > > > impossible, will there be a need for applications which navigate
> > > > > up and down the layers of headers to ensure they are consistent?
> > > > >
> > > > > Todd Boyle
> > > > >
> > > > > Christopher Ferris said 4/3
> > > > > > IMHO, our role should be to provide the content for the semantic
> > > > > > meaning of the elements we include in the header, etc.
> as well as
> > > > > > any information related to semantic equivalence with other
> existing
> > > > > > standards such as RosettaNet, EDI/INT, etc.
> > > > >
> > > > > [...]
> > > > > > > 2. namespaces
> > > > > > >
> > > > > > > MILR: Namespace can help avoid element name clashes,
> but IMO it
> > > doesn't
> > > > > > > addresss the equivalence of semantic entities across
> namespaces.
> > > > > > > Each option should be explored for possible appication within
> the
> > > ebXML
> > > > > > > header specification.
> > > > > > > I firmly believe the issues you raise, relative to the actual
> > > business
> > > > > > > transactions, needs to be addressed by the parties responsible
> for
> > > > > > > specifying these standards (e.g. OTA, et al).
> > > > > > >
> > > > > > > MILR:  I believe ebXML must adopt some XML syntax rules that
> > > adequately
> > > > > > > address the issue of semantics...
> > > >
> > > > --
> > > >     _/    _/             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.
> >
> >