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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: [ebxml-msg] Docbook sample based on v2.0

I've produced a snippet

Attachment: ebms_2_0.xml
Description: application/applefile

Attachment: ebms_2_0.xml
Description: application/xml

Title: OASIS ebXML Message Service Specification, Version 2.0

OASIS ebXML Message Service Specification, Version 2.0

Working Draft 2_0, 21 February 2002

Document identifier:

ebms-2_0

Abstract:

This specification focuses on defining a communications-protocol neutral method for exchanging electronic business messages. It defines specific enveloping constructs supporting reliable, secure delivery of business information. Furthermore, the specification defines a flexible enveloping technique, permitting messages to contain payloads of any format type. This versatility ensures legacy electronic business systems employing traditional syntaxes (i.e. UN/EDIFACT, ASC X12, or HL7) can leverage the advantages of the ebXML infrastructure along with users of emerging technologies.

Status:

This document specifies an ebXML Message Specification for the eBusiness community. Distribution of this document is unlimited.

Note

Implementers of this specification should consult the OASIS ebXML Messaging Services Technical Committee web site for current status and revisions to the specification (http://www.oasis-open.org/committees/ebxml-msg/ ).

  • Version 1.0 of this Technical Specification document was approved by the ebXML Plenary in May 2001.

  • Version 2.0 of this Technical Specification document was approved by the OASIS Messaging Team as a Technical Committee(TC) Specification, January 22, 2002.

  • Version 2.0 of this Technical Specification document is presented to the ASIS membership for consideration as an OASIS Technical Specification, April 2002.

Copyright © 2002 The Organization for the Advancement of Structured Information Standards [OASIS]

Table of Contents

1. Introduction
2. Summary of Contents of this Document
2.1. Terminology

Appendixes

A. Notices
B. Committee Members (Non-Normative)
C. Intellectual Property Rights
References

1. Introduction

This specification is one of a series of specifications realizing the vision of creating a single global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML based messages. The set of specifications enable a modular, yet complete electronic business framework. This specification focuses on defining a communications-protocol neutral method for exchanging electronic business messages. It defines specific enveloping constructs supporting reliable, secure delivery of business information. Furthermore, the specification defines a flexible enveloping technique, permitting messages to contain payloads of any format type. This versatility ensures legacy electronic business systems employing traditional syntaxes (i.e. UN/EDIFACT, ASC X12, or HL7) can leverage the advantages of the ebXML infrastructure along with users of emerging technologies.

2. Summary of Contents of this Document

This specification defines the ebXML Message Service Protocol enabling the secure and reliable exchange of messages between two parties. It includes descriptions of:

  • The ebXML Message structure used to package payload data for transport between parties.

  • The behavior of the Message Service Handler sending and receiving those messages over a data communications protocol.

This specification is independent of both the payload and the communications protocol used. Appendices to this specification describe how to use this specification with HTTP [RFC2616] and SMTP [RFC2821]. This specification is organized around the following topics:

Core Functionality

  • Packaging Specification – A description of how to package an ebXML Message and its associated parts into a form that can be sent using a communications protocol such as HTTP or SMTP (section 2.1),

  • ebXML SOAP Envelope Extensions – A specification of the structure and composition of the information necessary for an ebXML Message Service to generate or process an ebXML Message (section 2.3),

  • Error Handling – A description of how one ebXML Message Service reports errors it detects to another ebXML Message Service Handler (section 4.2),

  • Security – Provides a specification of the security semantics for ebXML Messages (section 4.1),

  • SyncReply – Indicates to the Next MSH whether or not replies are to be returned synchronously (section 4.3).

Additional Features

  • Reliable Messaging – The Reliable Messaging function defines an interoperable protocol where any two Message Service implementations can reliably exchange messages sent using once-and-only-once delivery semantics (section 6),

  • Message Status Service – A description of services enabling one service to discover the status of another Message Service Handler (MSH) or an individual message (section 7 and 8),

  • Message Order – The Order of message receipt by the To Party MSH can be guaranteed (section 9),

  • Multi-Hop – Messages may be sent through intermediary MSH nodes (section 10).

Appendices to this specification cover the following:

  • Appendix A Schema – This normative appendix contains XML schema definition [XMLSchema] for the ebXML SOAP Header and Body Extensions,

  • Appendix B Communications Protocol Envelope Mappings – This normative appendix describes how to transport ebXML Message Service compliant messages over HTTP and SMTP,

  • Appendix C Security Profiles – a discussion concerning Security Service Profiles.

2.1. Terminology

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC 2119].

A. Notices

Copyright © The Organization for the Advancement of Structured Information Standards [OASIS] 2001, 2002. All Rights Reserved.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS has been notified of intellectual property rights claimed in regard to some or all of the contents of this specification. For more information consult the online list of claimed rights.

B. Committee Members (Non-Normative)

The following individuals were members of the committee during the formulation of this document:

  • Ralph Berwanger, Individual Member

  • Dick Brooks, Individual Member

  • Doug Bunting, Sun Microsystems, Inc

  • David Burdett, Commerce One

  • Arvola Chan, TIBCO

  • Sanjay Cherian, Sterling Commerce

  • Cliff Collins, Sybase

  • Philippe DeSmedt, Individual Member

  • Colleen Evans, Sonic Software

  • Chris Ferris, Sun Microsystems, Inc

  • David Fischer, Drummond Group

  • Jim Galvin, Drummond Group

  • Brian Gibb, Sterling Commerce

  • Scott Hinkelman, IBM

  • Jim Hughes, Hewlett Packard

  • Kazunori Iwasa, Fujitsu Limited

  • Ian Jones, Individual Member

  • Brad Lund, Intel Corporation

  • Bob Miller, GE Global eXchange

  • Dale Moberg, Cyclone Commerce

  • Himagiri Mukkamala, Sybase

  • Bruce Pedretti, Hewlett-Packard

  • Yukinori Saito, Individual Member

  • Martin Sachs, IBM Research

  • Jeff Turpin, Cyclone Commerce

  • Aynur Unal, E2Open

  • Cedrec Vessell, DISA

  • Daniel Weinreb, eXcelon

  • Pete Wenzel, SeeBeyond

  • Prasad Yendluri, WebMethods

  • Sinisa Zimek, SAP

C. Intellectual Property Rights

For information on wether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the {technical-committee} web page (http://www.oasis-open.org/committees/ebxml-msg)

References

Normative

[RFC 2119] S. Bradner. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. IETF (Internet Engineering Task Force). 1997. 

of Docbook based on the 2.0 spec, and generated a HTML version using 
XSL so that everyone who is interested can compare and contrast source 
with output.

The XSL is the stock XSL for OASIS, found through 
http://www.oasis-open.org/spectools/

Regards,

Matt

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

Powered by eList eXpress LLC