[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
Ravi Manikundalam wrote: > NOTE: The reason I think folks like RosettaNet took and anybody else who has > based there packaging structure assuming DTD's as three or more separate XML > documents each packaged as individual MIME parts is that with DTD's you did > not have the luxury of using "Name Spaces" as you can more easily with > XML/XDR as well as XML/XSD combinations. Ravi, I am not sure I understand. Name spaces can be used when DTDs are used also. Could you address how the following benefits that I listed can be realized with schemas employing name spaces. Thanks. > -----Original Message----- > From: Prasad Yendluri [mailto:pyendluri@vitria.com] > Sent: Monday, April 10, 2000 6:44 PM > To: James McCarthy > Cc: ebXML Transport (E-mail) > Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics] > > Hi, > > Other frameworks like RosettaNet have discovered that it is desirable to > keep > the envelope and content disjoint (i.e. two different XML documents packed > together (with MIME) instead one XML document). > > Some of the advantages are: > > 1. Having fixed header DTD / Schema makes it easier / efficient to route the > message without having to look into the business content. > 2. Clear separation between different business (payload) documents and > headers > so that headers can be changed without impacting all business documents. > 3. Error can be reported back even if the business content can not be > parsed. > > Prasad > > James McCarthy wrote: > > > > -----Original Message----- > > > From: owner-ebxml-transport@lists.oasis-open.org > > > [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Dick > > > Brooks > > > Sent: Monday, April 10, 2000 5:41 PM > > > To: srh@us.ibm.com; David Burdett > > > Cc: Jon Bosak; ebXML-Transport@lists.oasis-open.org; Nicholas Kassem > > > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics] > > > > > > > > > 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. > > > > > > > No one is trying to "unravel" anything. The only real change that was > > suggested was that all pure XML content is packaged in a single MIME part > > using namespaces. This is currently being done by the Biztalk > specification > > and I have written SAX handlers to parse these messages. All non-XML will > > NOT be in the XML envelope but in separate MIME parts following the XML > > portion of the message. > > > > I think this is a very reasonable approach which is a great compromise > > between pure XML and MIME and takes full advantage of both specifications. > > MIME to separate mixed message types and namespaces to separate multiple > XML > > body parts all represented by a single ebXML header. > > > > > 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. > > > > > > > If the GIGABYTES of data is pure XML, IMHO, it is easier to process this > as > > an input stream using a SAX handler than it is to have to first separate > the > > message from its outer wrapper, MIME, and then parsing it using an XML > > parser. > > > > > - 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). > > > > > > > MIME will still be used for this no one is suggesting a change here. > > > > > - 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. > > > > > > > David's original post on this thread did not suggest a single package for > > everything. MIME would still be used and would be required for mixed > > payloads. > > > > > 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/ > > > > > > > > > > > > -----Original Message----- > > > From: srh@us.ibm.com [mailto:srh@us.ibm.com] > > > Sent: Monday, April 10, 2000 3:34 PM > > > To: David Burdett > > > Cc: '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] > > > > > > > > > > > > > > > David, > > > This was going to be my next question coming out of the Dallas meeting. > > > ---- why do we *need* the header envelope to be a seperate mime part > from > > > the payload envelope? ---- > > > > > > Without it, as you describe, essentially decouples the core ebXML > > > spec from > > > the lower level transport, > > > and essentially only demands that an application use a mime-based lower > > > transport only if binary > > > passed-by-value is required with high performance. As before, nothing > > > precludes an application > > > from base64ing a binary pass-by-value payload, and still leverage the > core > > > ebXML TRP specs > > > consistently over a transport that has nothing to do with mime. > > > > > > Somebody shoot this down. I think its difficult. > > > > > > Scott R. Hinkelman > > > IBM Austin > > > SWG Java Solutions > > > XML/Java Standards Architecture > > > Office: 512-823-8097 TL793-8097 > > > Home: 512-930-5675 > > > Cell: 512-940-0519 > > > srh@us.ibm.com > > > Fax: 512-838-1074 > > > > > > > > > > > > David Burdett <david.burdett@commerceone.com> on 04/10/2000 01:37:33 PM > > > > > > To: "'dick@8760.com'" <dick@8760.com>, Jon Bosak > > > <Jon.Bosak@eng.sun.com>, > > > ebXML-Transport@lists.oasis-open.org, Nicholas Kassem > > > <Nick.Kassem@eng.sun.com> > > > cc: > > > 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. > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC