[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [Fwd: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]]
David,
I'm trying to visualize this, and am not having much
luck;-)
Are you suggesting something along these lines?
Mime-Version: 1.0
Content-Type: application/ebXML; charset=UTF-8
Content-Length: 123456
<?xml version="1.0"?>
<ebXMLMessage>
<ebXMLHeader xmlns:header="http://ebXML.org/ebXMLHeader">
<header:To>nick@sun.com</header:To>
<header:From>chris.ferris@sun.com</header:From>
...
</ebXMLHeader>
<ebXMLPayload>
<Invoice xmlns:inv="http://ebXML.org/Invoice">
yadda yadda yadda
</Invoice>
</ebXMLPayload>
</ebXMLMessage>
and which would look like the following with a non-XML
payload "attachment" such as a PDF file?
Mime-Version: 1.0
Content-Type: multipart/related; boundary=qwertyuiop
Content-Length: 123456
--qwertyuiop
Content-Type: application/ebXML; charset=UTF-8
Content-Length: 12345
<?xml version="1.0"?>
<ebXMLMessage>
<ebXMLHeader xmlns:header="http://ebXML.org/ebXMLHeader">
<header:To>nick@sun.com</header:To>
<header:From>chris.ferris@sun.com</header:From>
...
</ebXMLHeader>
<ebXMLPayload>
<Invoice xmlns:inv="http://ebXML.org/Invoice">
yadda yadda yadda
</Invoice>
</ebXMLPayload>
</ebXMLMessage>
--qwertyuiop
Content-Type: application/pdf; name="somefile.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="somefile.pdf
JVBERi0xLjINJeLjz9MNCjk0IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA5NiANL0ggWyA5
ODMgNTM2IF0gDS9MIDIxNjM2NCANL0UgNDIzMDggDS9OIDE3IA0vVCAyMTQzNjYgDT4+IA1lbmRv
YmoNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTk0IDI5IA0wMDAwMDAwMDE2IDAwMDAwIG4gDTAwMDAwMDA5MjggMDAwMDAgbiANMDAw
--qwertyuiop
Cheers,
Chris
David Burdett wrote:
>
> 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