OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re:RE: Regarding the Thursday ebXML Conf Call

Perhaps we should do a better job of drawing a clear distinction between 
the outer wrapper of an ebXML message (which is where MIME comes in) and 
the various components of the message. As I recall we agreed that one of 
the key components of an ebXML message is the header. The header will be an 
XML document and the header analysis currently under way will presumably 
spell out a generic header and an extension mechanism for handling optional 
or domain specific headers. There will presumably be a number of other 
components (e.g. routing info, manifest ...) that will all be in XML. I 
thought we agreed that we want to deal with message payloads that may or 
may not be XML documents. Again assuming I am on the right track, then the 
question remains. How do we glue multiple objects, some in XML and others 
in XYZ format, into a discreet message. I think MIME may serve a very 
narrow purpose, i.e. as the glue. Is there an alternative glue standard 
that is pure XML *and* can be described using an XML schema language ? Just 
because multiple objects are glued together using MIME, does not 
subsequently bind us to an SMTP infrastructure.  I think we all agree that 
we would like to take a transport neutral approach. Am I correct in 
assuming that the purist view is that we should only deal with XML payloads ?


Senior Staff Engineer,
Java Software, Sun Microsystems Inc.
Cupertino, C.A.
(408) 863-3535

At 03:29 PM 3/2/00 -0500, Mark CRAWFORD wrote:
>     What was presented to us during our call today was that you were 
> selecting
>mime as "the" ebXML solution.  If that is not the case, then we don't have an
>issue.  Although I personally can't understand why anyone would want to use an
>antiquated technology such as e-mail to forward XML, especially in a 
>business to
>business exchange, I do see the need to accomodate folks desires.  If on the
>other hand, you are selecting mime as "the" ebXML solution, then I think that
>you will loose participation and support of the bulk of the XML community.
>     Mark
>Mark Crawford
>Research Fellow
>LMI Logistics Management Institute
>2000 Corporate Ridge, McLean, VA 22102-7805
>(703) 917-7177   Fax (703) 917-7518
>"Opportunity is what you make of it"
>____________________Reply Separator____________________
>Subject:    RE: Regarding the Thursday ebXML Conf Call
>Author: "Dick Brooks" <dick@8760.com>
>Date:       3/2/00 2:12 PM
>Rik, it appears the Requirements group needs to be made aware that people
>will want to send XML documents via E-mail and E-mail is not a W3C
>-----Original Message-----
>From: owner-ebxml-transport@lists.oasis-open.org
>[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Kit
>(Christopher) Lueder
>Sent: Thursday, March 02, 2000 1:30 PM
>To: Rik Drummond; Ebxml Transport
>Cc: Mike Rawlins; Mark CRAWFORD
>Subject: Regarding the Thursday ebXML Conf Call
>Regarding the EBXML Transport/R/P conference today, my understanding is
>that the group is pursuing a mime-based envelope structure? I mentioned
>that at the EBXML Requirements teleconference, which happened to be
>immediately after the TRP teleconf, and they weren't happy about that
>direction and hoped the TRP group will revisit that decision. In
>particular, it was suggested that there is an EBXML requirement for all
>EBXML specifications to be compliant with W3C technical specificatons.
>(Though Mike Rawlins said that the transport may be an exception.) I
>cite the relevant section from the EBXML Requirements document, which is
>to be released to the full EBXML body for review this Monday.
>1.2.1 ebXML Vision
>The ebXML vision is to deliver:
>"A single set of internationally agreed upon technical specifications
>that consist of common XML semantics and related document structures to
>facilitate global trade."
>This single set of ebXML technical specifications will create a Single
>Global Electronic Market.  To create this single global electronic
>market, this single set of ebXML technical specifications:
>  - is fully compliant with W3C XML technical specifications holding a
>recommended status,
>  - provides for interoperability within and between ebXML compliant
>trading partner applications,
>  -  maximizes interoperability and efficiency while providing a
>transition path from accredited electronic data interchange (EDI)
>standards and developing XML business standards, and
>  - will be submitted to an appropriate internationally recognized
>standards body for accreditation as an international standard.
>     _/    _/             Kit C. J. Lueder
>    _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
>   _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
>  _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
>_/    _/  _/    _/   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]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC