Exchange Header Envelope (XHE) Version 1.0

File or document headers have long been used to describe the information about a set of payloads in an entity that is kept separate and arm’s-length from the payloads themselves.

The metaphor of a paper envelope in which one places business documents for transport or management is apt to describe the role of an exchange header envelope in a container relationship to its payloads. Concepts of routing, authentication, non-repudiation and concealment all apply in both the metaphor and the electronic equivalent.

The Exchange Header Envelope (XHE) specifies an XML vocabulary [XML] expressing in machine-processable syntax the semantics of describing either a header to or an envelope of a set of payloads of content with information about that content. This vocabulary is modeled using the UN/CEFACT Core Component Technical Specification Version 2.01 [CCTS 2.01].

XHE, a specification developed jointly by UN/CEFACT and OASIS, is the successor to the UN/CEFACT Standard Business Document Header (SBDH) version 1.3 [SBDH] and the OASIS Business Document Envelope (BDE) version 1.1 [BDE].

This specification enumerates the information components of a payload header envelope and formally describes the semantics of each component.

This specification mandates a suite of XML schemas [XSD1][XSD2] and additional limitations describing the document constraints against which a conforming instance SHALL validate without error.

The XHE is designed to be either a header as an integral part of a business document (e.g. either XML instance document or EDI interchange), an object associated with the business document itself, or as an envelope functioning as wrapper that contains one or more business documents.

There exist several business document exchange architectures and approaches, some using EDI formats and approaches, some using XML document types, and yet others use different document formats or non-standardized approaches. The XHE is designed to work with any document format and business process, whether standardized or not, and as such supports both the EDI, the XML and any other e-business community. Including a XHE in each instance of the business document reduces the effort needed to route and process documents and permits trading partner organizations to use different implementation approaches.

When implementing EDI, the provision of an additional business document header may not always be necessary, since EDI interchanges already contain functionality for some of the information in the XHE. An example is the EDIFACT UNB interchange header, the UNH message header, and the ‘function’ part of the BGM. The XHE specification allows for this existing approach and provides an option to express additional functionality, such as service and correlation information.

Many users, implementers and supporting industry standard bodies are in agreement on the need for an Exchange Header Envelope. In their business-to-business activities, the XHE facilitates several different business needs:

In addition to header functions provided by the XHE for routing and/or processing of business documents, there is the need for a completely separate technical communications transport layer. This deals with communications protocols and physical addresses which are outside the scope of this technical specification. Transport specifications including EDIINT-AS2 and ebXML Message Service (ebMS) are among a number of possible transport options that address technical communications needs by defining a separate technical header. The transport layer is completely outside the scope as it is a different layer of the stack.

This specification accommodates both CEFACT and OASIS naming conventions of all semantic identifiers by documenting the two values for every business information entity. In each table row in Section 2, “Header and envelope information” the semantic identifiers are provided in two sub-rows, the upper one carrying the OASIS semantic identifier and the lower one carrying the CEFACT semantic identifier.

All organizations that manage infrastructure operations and business processes for various functional areas (e.g. ordering, invoicing, planning, or financial), all service provider organizations and associations, as well as e-business networks and infrastructures, which create, route and process business documents can benefit from the use of the Exchange Header Envelope.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, OPTIONAL and SHOULD in this document are to be interpreted as described in [RFC 2119].

Information about the complete set of payloads includes the following:

Information about an individual payload within the set of payloads includes the following:

The information for an individual payload ends with an additional optional payload content item that is neither a BBIE nor an ASBIE and so is not modeled using CCTS. Rather, this content item is a schema artefact. This content item has the cardinality 0..1. This content item can have as its child either text only (no elements) or a single element, but not a combination of both nor more than one element. See Section 5.6.3, “Payload content” for more information.

There are two content data type schema fragments in the common subdirectory, one for each of the extension content and the payload content. These are the only schemas intended to be edited by users should they wish to validate the content of their extensions or payloads. No changes are necessary to the schemas if it is not important to validate these portions of the document.

Should users wish to impose constraints on the extension or the payload contents, the only edits necessary of the content schema are for the importation of the schemas to be engaged for validation purposes. No edits are necessary for the content element, though one may wish to do so to exclude content other than that for which schemas are provided.

The extension content schema fragment describes constraints on content placed in extensions.

The extension content element’s name is <{extensions prefix}:ExtensionContent>, for example, <ext:ExtensionContent>. It is the last child element of <{extensions prefix}:XHEExtension>.

Any given extension content may have zero or one apex (or top-most) element in the XML element tree. The absence of content is provided for situations where a processing application chooses to remove foreign unrecognized-namespace elements from the XML element tree.

The distributed version of this file imports the version of XAdES schemas that are current at the time of publication. XAdES constructs are used within W3C XML Digital Signatures. These import directives can be replaced with the importation of future versions of XAdES schemas as needed.

The payload content schema fragment describes constraints on content placed in payloads.

The payload content element’s name is <{aggregate prefix}:PayloadContent>, for example, <eac:PayloadContent>. It is the last child element of <{aggregate prefix}:Payload>.

Any given payload content element may have as its child exactly one apex (or top-most) element in the XML element tree, or it may consist solely of text that would typically represent encrypted content or non-XML content. Special care needs to be taken that all non-XML payload content is encoded according to XML text encoding rules, such as the escaping of special markup characters, so as to permit an XML processing application to correctly interpret the non-XML content.

The schema declarations are unable to trigger a constraint error in the situation where the payload content has a combination of both text and a single element. Detecting such a condition is the responsibility of the processing agent.

The schema declarations are unable to trigger a constraint error in the situation where the payload content is empty. Detecting such a condition is the responsibility of the processing agent.