Business Document Envelope Version 1.1
Committee Specification Draft 02 / Public Review Draft 02
20 July 2016
- Specification URIs
- This version:
-
http://docs.oasis-open.org/bdxr/bdx-bde/v1.1/csprd02/bdx-bde-v1.1-csprd02.xml
(Authoritative)
http://docs.oasis-open.org/bdxr/bdx-bde/v1.1/csprd02/bdx-bde-v1.1-csprd02.html
http://docs.oasis-open.org/bdxr/bdx-bde/v1.1/csprd02/bdx-bde-v1.1-csprd02.pdf
- Technical Committee:
- OASIS Business Document Exchange (BDXR) TC
- Chair:
- Kenneth Bengtsson (kenneth@alfa1lab.com), Alfa1lab
- Editors:
-
G. Ken Holman
(gkholman@CraneSoftwrights.com),
Crane Softwrights Ltd.
Kenneth Bengtsson (kenneth@alfa1lab.com), Alfa1lab
- Related work:
-
This specification supersedes:
Business Document Envelope Version 1.0 Edited by G. Ken Holman and Kenneth Bengtsson. 02 August 2015. OASIS Committee Specification 01. Latest version: http://docs.oasis-open.org/bdxr/bdx-bde/v1.0/bdx-bde-v1.0.html.
- Declared XML Namespaces:
- Abstract:
-
This specification defines a business-oriented artefact enveloping a payload of one or more business documents or other artefacts with supplemental semantic information about the collection of payloads as a whole. This is distinct from any transport-layer infrastructure envelope that may be required to propagate documents from one system to another. A business document envelope describes contextual information important to the sender and receiver about the payloads, without having to modify the payloads in any fashion.
- Status:
-
This document was last revised or approved by the OASIS Business Document Exchange (BDXR) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=bdxr#technical.
TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/bdxr/.
For information on whether 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 at https://www.oasis-open.org/committees/bdxr/ipr.php.
- Citation format:
-
When referencing this specification the following citation format should be used:
[BDX-BDE-V1.1] Business Document Envelope Version 1.1. Edited by G. Ken Holman and Kenneth Bengtsson. 20 July 2016. OASIS Committee Specification Draft 02 / Public Review Draft 02. http://docs.oasis-open.org/bdxr/bdx-bde/v1.1/csprd02/bdx-bde-v1.1-csprd02.html. Latest version: http://docs.oasis-open.org/bdxr/bdx-bde/v1.1/bdx-bde-v1.1.html.
Notices
Copyright © OASIS Open 2016. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website.
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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, 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 OWNERSHIP RIGHTS AND ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
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’ procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on 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 implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name “OASIS” is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark.php for guidance.
Table of Contents
- 1 Introduction
- 2 Envelope information
- 3 XML schemas
- 4 Conformance
Appendixes
1 Introduction [comment?]
1.1 A business document envelope [comment?]
The metaphor of a paper envelope in which one places business documents for transport or management is apt to describe the role of a business document envelope in relationship to its payloads. Concepts of routing, authentication, non-repudiation and concealment all apply in both the metaphor and the electronic equivalent.
The OASIS Business Document Envelope specifies an XML vocabulary [XML] expressing in machine-processable syntax the semantics of enveloping a payload of content with information about that content.
This specification details example candidate scenarios in which a payload envelope plays a role, and the use cases identified in such scenarios.
This specification enumerates the information components of the payload 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 MUST validate without error.
Normative markings [comment?]
All clauses not marked as "non-normative" and also not a subclause of a clause marked as "non-normative" are to be considered normative. All notes and examples are non-normative.
1.2 Terminology [comment?]
1.2.1 Key words [comment?]
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].
1.2.2 Terms and Definitions [comment?]
- schema
-
An expression of constraints placed on XML content.
- structural schema
-
An expression of structural constraints placed on XML elements, attributes and textual content.
- value constraints
-
An expression of constraints placed on the values of attributes and textual content.
1.2.3 Symbols and Abbreviations [comment?]
1.2.4 Key concepts [comment?]
- validation
-
The act of testing an XML document against a set of structural constraints (as expressed in a schema) or value constrains (as expressed in an arbitrary XML processing language, for example, XSLT).
1.3 Normative References [comment?]
[CCTS 2.01] UN/CEFACT Core Components Technical Specification, Version 2.0115 November 2003 http://www.unece.org/fileadmin/DAM/cefact/codesfortrade/CCTS/CCTS_V2-01_Final.pdf
[genericode] Code List Representation (Genericode) Version 1.0. Edited by Anthony B. Coates. 28 December 2007. Committee Specification 01. http://docs.oasis-open.org/codelist/genericode/. Latest version: http://docs.oasis-open.org/codelist/genericode/doc/oasis-code-list-representation-genericode.html.
[RFC 2119] , Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition), , , , , , Editors, W3C Recommendation, 26 November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/. Latest version available at http://www.w3.org/TR/xml.
[XSD1] XML Schema Part 1: Structures Second Edition, , , , , Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/. Latest version available at http://www.w3.org/TR/xmlschema-1.
[XSD2] XML Schema Part 2: Datatypes Second Edition, , , Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Latest version available at http://www.w3.org/TR/xmlschema-2.
1.4 Non-Normative References [comment?]
[CMS] Cryptographic Message Syntax (CMS), , September 2009, https://tools.ietf.org/html/rfc5652.
[PGP] OpenPGP Message Format, , , , , , November 2007, https://tools.ietf.org/html/rfc4880.
[xmldsig] XML-Signature Syntax and Processing Version 1.1, , , , , , , , Editors, W3C Recommendation, 11 April 2013, http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/. Latest version available at http://www.w3.org/TR/xmldsig-core1.
[XMLEnc] XML Encryption Syntax and Processing, , , 10 December 2002, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.
2 Envelope information [comment?]
2.1 Class diagram [comment?]
The CCTS-modeled classes of information in the envelope model, and the relationships between them and the additional schema fragments that satisfy non-CCTS-modeled content are depicted in Figure 1, “Information classes”.
![[Information classes]](art/bde-classes.png)
Note [comment?]
The requirements upon which the envelope semantics were chosen are listed in Appendix C, Requirements (Non-Normative)
2.2 The envelope class [comment?]
2.2.1 CCTS and non-CCTS envelope information [comment?]
The information described in an envelope is documented in two parts.
The basic information related to the envelope is modeled as CCTS classes.
Additional information related to the envelope is not modeled as CCTS classes. This includes extension and signature information. Such information is realized in the schema expressions as additional document constraints.
2.2.2 Basic envelope information [comment?]
The CCTS-modeled objects in the envelope class are as follows, indicating the requirements being met by the object:
|
Supports |
Name (Unqualified data type) |
Description |
Crd |
Rationale |
| BDE-02 |
BDEVersionID (Identifier) |
The version of the specific envelope model in use. | 0..1 | To allow coexistence of different versions of envelopes without using the namespace. The element identifies which syntax version is being used. |
| BDE-18 |
CustomizationID (Identifier) |
The identification of a customization or use of the envelope model. | 0..1 | To distinguish a particular set of conventions of use of the envelope, including subsetting, expected extensions and applications. |
| BDE-01 |
ID (Identifier) |
Unique ID for the envelope for tracking purposes. | 1..1 | The envelope needs to be tracked. |
| BDE-03 |
CreationDateTime (DateTime) |
Date and time when the envelope was created. | 1..1 | The creation date and time needs to be recorded. |
| BDE-17 |
TestIndicator (Indicator) |
There is a requirement to identify that the content inside the envelope is for test purposes. | 0..1 | The test flag enables the recipient to identify an incoming message as a test or production message. |
| BDE-04 |
FromParty (Party class) |
An unambiguous identification of the party that originated the envelope. | 0..1 | The sender need not be identified, but if so, is done with an identifier, such as for example a GS1 GLN identifier. |
| BDE-05 |
ToParty (Party class) |
Unambiguous identification of the parties to receive the envelope. | 1..n | The receivers each need to be identified by some identifier, such as for example a GS1 GLN identifier. |
| BDE-07 |
Payload (Payload class) |
The actual payload, such as an invoice, to be processed at next level. | 1..n | An envelope without payload serves no purpose. |
2.2.3 Additional envelope information [comment?]
2.2.3.1 Extension information [comment?]
Through the use of extension metadata and content, additional user-defined information that is not modelled by the CCTS classes can be added to the envelope instance.
The extension point is an OPTIONAL construct as the initial child of the document element. The extension point, when it exists, MUST contain one or more user-defined extensions, with each extension wrapped with OPTIONAL extension metadata identifying properties of the extension.
|
Name (Unqualified Data Type) |
Description |
Crd |
Rationale |
|
BDEExtensions |
A container for all extensions present in the document. | 0..1 | This is the single point of access to all extensions as the first child of the main document. |
|
BDEExtension |
A single extension for private use. | 1..n | There may be many extensions added to a single document. |
|
ExtensionID (Identifier) |
An identifier for the Extension assigned by the creator of the extension. | 0..1 | This identifies the extension amongst other extensions within the document. |
|
ExtensionName (Name) |
A name for the Extension assigned by the creator of the extension. | 0..1 | This identifies the extension in natural language within the document. |
|
ExtensionAgencyID (Identifier) |
An agency that maintains one or more Extensions. | 0..1 | This identifies who created the extension. |
|
ExtensionAgencyName (Name) |
The name of the agency that maintains the Extension. | 0..1 | This identifies who created the extension. |
|
ExtensionAgencyURI (Identifier) |
A URI for the Agency that maintains the Extension. | 0..1 | This identifies who created the extension. |
|
ExtensionVersionID (Identifier) |
The version of the Extension. | 0..1 | This distinguishes one version of the extension from another. |
|
ExtensionURI (Identifier) |
A URI for the Extension. | 0..1 | This identifies the extension amongst other extensions outside of any document. |
|
ExtensionReasonCode (Code) |
A code for reason the Extension is being included. | 0..1 | This gives the author the opportunity to give rationale by way of a code. |
|
ExtensionReason (Text) |
A description of the reason for the Extension. | 0..1 | This gives the author the opportunity to give rationale by way of a text description. |
|
ExtensionContent |
The definition of the extension content. | 1 | This is the parent element of the extension content. |
There are no restrictions on the extension content. See Section 3.5.2, “Extension content” for more information.
2.2.3.2 Signature information [comment?]
This meets requirement BDE-06.
Through the use of the W3C Digital Signature [xmldsig] zero or more signatures can be added to the envelope.
The signatures are grouped as the final children of the document element.
Note [comment?]
The val/ subdirectory includes examples of
envelope documents with bona fide digital signatures as described in
Appendix D,
Demonstration environment (Non-Normative).
2.3 The party class [comment?]
The CCTS-modeled objects in the party class are as follows, indicating the requirements being met by the object:
|
Supports |
Name (Unqualified Data Type) |
Description |
Crd |
Rationale |
| BDE-04, BDE-05 |
ID (Identifier) |
An unambiguous identification of a party. | 1..n | The party needs to be identified by some identifier, such as for example a GS1 GLN identifier. |
Note [comment?]
The Identifier unqualified data type offers various attributes that distinguish the semantics expressed by the identifier element value, as summarized in the Identifier data type summary. The element content provides for any normalized string value, which includes the expression of a Uniform Resource Identifier (URI) if needed.
2.4 The payload class [comment?]
2.4.1 CCTS and non-CCTS payload information [comment?]
The information described in a payload is documented in two parts.
The basic information related to the payload is modeled as CCTS classes.
The payload content is not modeled as CCTS classes. Such information is realized in the schema expressions as additional document constraints. The rationale for this element is that it is required to be able to include the payload information when that payload information is intended to be part of the envelope. The name of the item is "PayloadContent", its cardinality is "0..1" and its description is:
The content of the payload when it is included in the envelope.
In a single instance of the payload class, the payload external reference and the payload content are mutually exclusive and one of them MUST exist.
2.4.2 Basic payload information [comment?]
The CCTS-modeled objects in the payload class are as follows, indicating the requirements being met by the object:
|
Supports |
Name (Unqualified Data Type) |
Description |
Crd |
Rationale |
| BDE-08 |
ID (Identifier) |
A unique identification of the payloads contained within the envelope. | 0..1 | Required to be able to identify the content of the payload without having to look inside the envelope. |
| BDE-09 |
DocumentTypeID (Identifier) |
This element identifies the type of the payload instance in the envelope. | 0..1 | To enable a Service registry lookup to verify and identify the type of payload. |
| BDE-11 |
CustomizationID (Identifier) |
Identifies the customization that applies to the received document. | 0..1 | May be used to control validation of the content of the document that is contained in the document instance. |
| BDE-12 |
ProfileID (Identifier) |
Identifies the profile that the payload document is part of. | 0..1 | May be used to route the incoming document to the correct process dependent on which business process the payload instance is part of, e.g. an order response that is part of a process defined in the identified profile. |
| BDE-12 |
ProfileExecutionID (Identifier) |
Identifies the particular instance of an executing profile that the payload document is part of. | 0..1 | This distinguishes between multiple executing instances of a given profile. |
| BDE-13 |
HandlingServiceID (Identifier) |
Identifies the service that should process the payload instance. | 0..1 | Can be used to look up the target service that should be used to process the payload instance. |
| BDE-09 |
InstanceSyntaxID (Identifier) |
Identifies the syntax that the payload document is expressed in. | 0..1 | Makes it possible to route the incoming message to the appropriate process depending on the document syntax. |
| BDE-15 |
InstanceEncryptionIndicator (Indicator) |
An indicator to state whether the payload instance is encrypted or not. | 0..1 | The fact that a payload is encrypted may need to be identified in order to ensure correct processing. |
| BDE-15 |
InstanceEncryptionMethod (Text) |
The method used to encrypte the payload instance. | 0..1 | The fact that a payload is encrypted may need to be identified in order to ensure correct processing. |
| BDE-16 |
InstanceHashValue (Text) |
Hash total of the unencrypted payload document. | 0..1 | The hash provides a check of the integrity of any unencrypted payload. |
| BDE-16 |
InstanceHashAlgorithm (Text) |
Algorithm used to calculate the hash total of the unencrypted payload document. | 0..1 | Different schemes for calculating the hash are possible to be used and so should be identified. |
| BDE-20 |
InstanceDecryptionInformationExternalReference (External Reference class) |
Decryption information that is available external to the envelope. | 0..1 | To give general information regarding the decryption of an encrypted payload instance. |
| BDE-20 |
InstanceDecryptionKeyExternalReference (External Reference class) |
Decryption key data that is available external to the envelope. | 0..1 | To give specific key information regarding the decryption of an encrypted payload instance. |
| BDE-10 |
RelevantExternalReference (External Reference class) |
A reference to a business case, document or other issues which are relevant to the handling of the envelope. | 0..n | To enable routing and other handling, such as opening of an envelope based on the referenced information such as a reference to a specific call for tender to which the envelope contains a response (e.g. a tender). |
| BDE-19 |
PayloadExternalReference (External Reference class) |
The reference to the payload when it is not included within the envelope. | 0..1 | In use cases where the sender wants to make the recipient aware of the existence of a document stored at an external location and is not contained within the business document envelope itself. |
2.4.3 Additional payload information [comment?]
Certain information related to the payload is not modeled as a CCTS class, rather, it is realized in the schema expressions as a set of additional document constraints. See Section 3.5.3, “Payload content” for more details.
2.4.4 Positional semantics of multiple payloads [comment?]
When there exists more than one payload in a business document envelope, the first payload in document order SHALL be considered the primary payload.
2.4.5 Non-XML payload syntax constraint [comment?]
When the payload syntax is not XML it MUST be encoded in the payload content in such a way as not to interfere with the XML processing of the content as simple text. Sensitive XML markup characters in simple text, the "<", "&" and ">", MUST be escaped using an entity or a numeric character reference.
Note [comment?]
Binary payloads cannot be processed as simple text in an XML document without being encoded. To be well-formed, such content is encoded using a technique such as Base64 or Xxencoding, both of which can be used in the raw without character escaping. A technique such as Uuencode cannot be used in the raw because its encoded repertoire includes sensitive XML markup characters that would need to be escaped in order to be used.
2.5 The external reference class [comment?]
The CCTS-modeled objects in the external reference class are as follows, indicating the requirements being met by the object:
|
Supports |
Name (Unqualified Data Type) |
Description |
Crd |
Rationale |
| BDE-10, BDE-19 |
ID (Identifier) |
An identifier through which an external resource can be located or de-referenced. | 1..n | Resources not contained within the envelope need to be identified by some mechanism through which the resource can be obtained. |
| BDE-21 |
AvailabilityStartDateTime (DateTime) |
The start date and time when the information is available. | 0..1 | Resources may be constrained by when in time they first become available. |
| BDE-21 |
AvailabilityEndDateTime (DateTime) |
The end date and time when the information is available. | 0..1 | Resources may be constrained by when in time they are no longer available. |
| BDE-21 |
Login (Text) |
Text describing any login details to access the information. | 0..1 | Access to a resource may be constrained by a login credential. |
| BDE-21 |
Password (Text) |
A password needed to access the information. | 0..1 | Access to a resource may be constrained by a password credential. |
Note [comment?]
The Identifier unqualified data type offers various attributes that distinguish the semantics expressed by the identifier element value, as summarized in the Identifier data type summary. The element content provides for any normalized string value, which includes the expression of a Uniform Resource Identifier (URI) if needed.
2.6 Model expression [comment?]
The document model is expressed in three ways, found in three files of the model subdirectory:
-
-
-
model information expressed in an Open Office spreadsheet
-
-
-
model information expressed in an Excel spreadsheet
-
-
-
model information expressed in a genericode [genericode] file
-
-
3 XML schemas [comment?]
3.1 Schema expression [comment?]
The structural document constraints of the envelope are expressed normatively as a set of W3C XSD XML Schemas [XSD1][XSD2].
3.2 The schema subdirectories [comment?]
The schemas are delivered in two subdirectories:
In both subdirectories there is a single subdirectory of common files:
-
-
included schema fragments by any document fragment
-
3.3 The envelope schema [comment?]
The following is the only Document ABIE schema:
-
-
the base envelope schema fragment that incorporates other schema fragments
-
3.4 Non-content data type common schemas [comment?]
The following are read-only schema fragments in the common subdirectory:
-
BDE-CommonAggregateComponents-1.1.xsd-
the Library ABIE element declarations
-
-
BDE-CommonBasicComponents-1.1.xsd-
the Library BBIE element declarations
-
-
BDE-CommonExtensionComponents-1.1.xsd-
the Document ABIE extension metadata declarations
-
-
BDE-QualifiedDataTypes-1.1.xsd-
the qualified data types (empty; none are defined)
-
-
BDE-UnqualifiedDataTypes-1.1.xsd-
the unqualified data types based on the core component types
-
see Section 3.6, “Unqualified data type attributes” for more details
-
-
-
the XML Digital Signature 1.1 schema driver fragment copyrighted by W3C
-
-
-
the XML Digital Signature 1.1 schema fragment copyrighted by W3C
-
-
BDE-xmldsig-core-schema-1.1.xsd-
the XML Digital Signature Core schema fragment copyrighted by W3C
-
-
-
the Core Component Types schema fragment copyrighted by UN/CEFACT
-
3.5 Content data type common schemas [comment?]
3.5.1 Modifiable schema fragments [comment?]
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.
3.5.2 Extension content [comment?]
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
element child of <{extensions
prefix}:BDEExtension>.
Any given extension content may have as its child at most 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 elide foreign unrecognized-namespace elements from the XML element tree.
The distributed version of this file imports the version of XAdES schemas 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.
-
BDE-XAdES01903v132-201601-1.1.xsd-
the v1.3.2 XAdES schema fragment from the etsi.org web site
-
-
BDE-XAdES01903v141-201601-1.1.xsd-
the v1.4.1 XAdES schema fragment from the etsi.org web site
-
3.5.3 Payload content [comment?]
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 element child 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 prevent flagging the payload content having a combination of both text and a single element as a constraint error. Detecting such a condition is the responsibility of the processing agent.
The schema declarations are unable to prevent flagging the payload content having empty content as a constraint error. Detecting such a condition is the responsibility of the processing agent.
3.6 Unqualified data type attributes [comment?]
In the Business Document Envelope model each BBIE is indicated to have a particular component name (specifying the element name) and to be of a particular unqualified data type (specifying the base type value constraints and the attributes).
Based on the 10 approved core component types described in section 8.1 of [CCTS 2.01], there are 20 available unqualified data types for BBIE values. Each data type has a constraint on its content (the component) and a possibly-empty selection of available possibly-mandatory attributes (the supplementary components).
Note [comment?]
Not all of the unqualified data types listed in this table are used in the standardized components of the envelope. All defined types are enumerated here for completeness in the event that a CCTS-based extension is created by a community of users that relies on one of the unqualified data types not used by the standardized components of the envelope.
4 Conformance [comment?]
A Business Document Envelope instance exhibits conformance when complying with all of the following criteria:
-
The instance MUST NOT violate any document constraints expressed by the schema in Section 3.3, “The envelope schema”
-
Any XML element that is not extension content MUST NOT be empty.
-
The
<{aggregate prefix}:Payloadelement SHALL have one or the other of the<{aggregate prefix}:PayloadContent>element child or the<{aggregate prefix}:PayloadExternalReference>element child (that is, it MUST NOT have both). -
The
<{aggregate prefix}:PayloadContent>element SHALL NOT have a combination of text and an element (that is, it MUST either be a non-empty string of text or be a single element).
Appendix A Package structure (Non-Normative) [comment?]
This Committee Specification Draft 02 / Public Review Draft 02 is published as a zip archive in the http://docs.oasis-open.org/bdxr/bdx-bde/v1.1/csprd02/ directory. Unzipping this archive creates a directory tree containing a number of files and subdirectories. Note that while the two XML files comprise the revisable version of this specification, this revisable XML may not be directly viewable in all currently available web browsers.
The base directory has the following files:
bdx-bde-v1.1-csprd02.xmlThe revisable form of the document.
bdx-bde-v1.1-csprd02.htmlAn HTML rendering of the document.
bdx-bde-v1.1-csprd02.pdfA PDF rendering of the document.
These are the non-normative subdirectories in the package:
artDiagrams and illustrations used in this specification.
dbDocBook stylesheets for viewing in HTML the XML of this work product.
valDemonstrative validation of the example instances with the envelope schemas.
See Appendix D, Demonstration environment (Non-Normative) for details.
The normative subdirectories in the package are listed in normative clauses.
Appendix B Revision History (Non-Normative) [comment?]
B.1 Major version BDE 1.0 [comment?]
BDE version 1.0 Committee Specification 01 was published 02 August 2105. Version 1.0 established the namespaces to be used for all minor revisions of the Business Document Envelope.
B.2 Minor Revision BDE 1.1 [comment?]
B.2.1 Backwards Compatibility [comment?]
BDE version 1.1 is a minor revision of BDE version 1.0. This new version only adds new business objects to meet user requirements identified after the completion of BDE version 1.0.
Version 1.1 is fully backward compatible to version 1.0 in that every XML instance that validates with the BDE 1.0 schemas will also validate with the BDE 1.1 schemas.
B.2.2 Schema changes from BDE 1.0 to BDE 1.1 [comment?]
B.2.2.1 Changes to Library Elements, BDE 1.0 to BDE 1.1 [comment?]
Table B.1. Changes to Library Elements BDE 1.1 from BDE 1.0
| Aggregate BIE | Basic or Association BIE | Changes for BDE-1.1 |
|---|---|---|
| ExternalReference | ||
| AvailabilityStartDateTime | Added | |
| AvailabilityEndDateTime | Added | |
| Login | Added | |
| Password | Added | |
| Party | ||
| ID | Changed cardinality from 1 to 1..n | |
| Payload | ||
| InstanceDecryptionInformationExternalReference | Added | |
| InstanceDecryptionKeyExternalReference | Added |
Note [comment?]
The change in cardinality for the ID child
of Party is a repair to a fault in the
published BDE 1.0 schema expression of the BDE 1.0 specification's
constraints. This is not a change reflecting new user requirements.
B.2.2.2 Changes to Document Elements, BDE 1.0 to BDE 1.1 [comment?]
Appendix C Requirements (Non-Normative) [comment?]
C.1 High-level and non-functional requirements [comment?]
-
The BDE must be an electronic envelope and universally understandable document header that allows its originator to send one or more electronic business documents to a recipient.
-
The BDE must be payload agnostic, meaning that it must function completely independently from its content.
-
The BDE must be an independent work product with no bindings or references to specific document standards.
-
The BDE must be transport protocol agnostic, meaning that it must be possible to send and receive a BDE through any file transfer protocol.
-
It must be possible to route a BDE through several intermediaries and networks.
-
It must be possible for the sender and receiver of a BDE to keep its payload confidential from end to end.
-
It must be possible for the receiver of a BDE to verify the integrity of its payload.
-
A gateway or intermediary must be able to route a BDE without any knowledge of its payload.
-
The BDE should support business scenarios where it is required to unambiguously establish the identity of its sender.
-
The BDE should support business scenarios where it is required to keep the identity of its sender hidden.
C.2 Functional requirements [comment?]
Appendix D Demonstration environment (Non-Normative) [comment?]
A working example of using the schemas with an XML instance is demonstrated in
the val/ directory. This directory has a number of
simple test files:
-
simpleExample.xml-
a simple envelope with three payload instances, the second of which is simple text (note the escaped special characters) and the other two of which are XML
<?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns="http://docs.oasis-open.org/bdxr/ns/bde/1.0/Envelope" xmlns:ebc="http://docs.oasis-open.org/bdxr/ns/bde/1.0/BasicComponents" xmlns:eac="http://docs.oasis-open.org/bdxr/ns/bde/1.0/AggregateComponents"> <ebc:ID>123</ebc:ID> <ebc:CreationDateTime>2015-02-08T20:34:00-04:00</ebc:CreationDateTime> <eac:FromParty> <ebc:ID>A</ebc:ID> </eac:FromParty> <eac:ToParty> <ebc:ID>B</ebc:ID> </eac:ToParty> <eac:Payload> <eac:PayloadContent> <myDocumentHere> <myElement>My Content</myElement> <myElement>My Content</myElement> <myElement>My Content</myElement> </myDocumentHere> </eac:PayloadContent> </eac:Payload> <eac:Payload> <eac:PayloadContent> Non-XML payload here, with sensitive characters escaped such as &, < and ]]>. Any text, provided it has been escaped, can be included in a payload. </eac:PayloadContent> </eac:Payload> <eac:Payload> <eac:PayloadContent> <myOtherDocumentHere> <myOtherElement>My Content</myOtherElement> <myOtherElement>My Content</myOtherElement> <myOtherElement>My Content</myOtherElement> </myOtherDocumentHere> </eac:PayloadContent> </eac:Payload> </Envelope> -
-
simpleExampleFailSyntax.xml-
an envelope document with an XML well-formedness error (the end tag for the creation date and time is missing the closing right-angle bracket)
-
-
simpleExampleFailModel.xml-
an envelope document with an XML validity error (a misspelled element for the creation date and time)
-
-
simpleExampleExtension.xml-
a simple envelope with a user-defined extension adding information to the envelope
-
-
simpleExampleDecrypt.xml-
a simple envelope referencing time-sensitive decryption information
-
-
simpleExampleMultipleToPartyXMLEnc1.xml-
an envelope with multiple
ToPartyelements and encrypted content (see Appendix E, Encrypting payloads to multiple recipients (Non-Normative))
-
-
simpleExampleSignedNotFinal.xml-
a simple envelope digitally signed with a single signature in such a way that allows additional signatures to be embedded in the envelope
-
-
simpleExampleSignedFinal.xml-
a simple envelope digitally signed with a single signature in such a way that does not allow additional signatures to be embedded in the envelope
-
-
simpleExampleSignedNotFinalAdditional.xml-
a simple envelope digitally signed with two signatures, having added one to
simpleExampleSignedNotFinal.xml
-
-
simpleExampleSignedFinalAdditionalFail.xml-
a simple envelope digitally signed with two signatures, having added one to
simpleExampleSignedFinal.xml -
the document validates against the BDE schemas, however digital signature verification software flags this as the final signature being invalid because additional information (the second signature) was added to the document
-
-
simpleExampleSignedDetached.xml-
the detached digital signature of
simpleExample.xml, signed in such a way that allows additional signatures to be embedded in the envelope -
this is an instance of the W3C digital signature vocabulary and is not an instance of the business document envelope, and so this is not validated as part of the test script
-
Note [comment?]
The digital signatures in these test files are bona fide and can be verified with suitable digital signature software.
To invoke the schemas with the demonstration instances, navigate to the directory and invoke the test script:
-
in Windows:
test.bat -
in shell:
sh test.sh
The result on the screen should appear as follows:
val $ sh test.sh
############################################################
Validating simpleExample.xml
############################################################
============== Phase 1: XSD schema validation ==============
No schema validation errors.
============ Phase 2: XSLT code list validation ============
No code list validation errors.
############################################################
Validating simpleExampleFailSyntax.xml
############################################################
============== Phase 1: XSD schema validation ==============
org.xml.sax.SAXParseException: The end-tag for element type
"ebc:CreationDateTime" must end with a '>' delimiter.
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:277)
at com.nwalsh.parsers.XJParser.xsdParse(Unknown Source)
at com.nwalsh.parsers.XJParser.parse(Unknown Source)
at com.nwalsh.parsers.XJParse.run(Unknown Source)
at com.nwalsh.parsers.XJParse.main(Unknown Source)
Exception in thread "main" java.lang.NullPointerException
at com.nwalsh.parsers.XJParser.printParseStats(Unknown Source)
at com.nwalsh.parsers.XJParse.run(Unknown Source)
at com.nwalsh.parsers.XJParse.main(Unknown Source)
Attempting well-formed, namespace-aware parse
Fatal error:file:///Users/admin/t/artefacts-bdx-bde-v1.0-csd01wd01-test/
val/simpleExampleFailSyntax.xml:7:3:The end-tag for element type
"ebc:CreationDateTime" must end with a '>' delimiter.
############################################################
Validating simpleExampleFailModel.xml
############################################################
============== Phase 1: XSD schema validation ==============
Attempting well-formed, namespace-aware parse
Error:file:///Users/admin/t/artefacts-bdx-bde-v1.0-csd01wd01-test/val/
simpleExampleFailModel.xml:6:26:cvc-complex-type.2.4.a: Invalid
content was found starting with element 'ebc:CreationDateTimex'. One
of '{"http://docs.oasis-open.org/bdxr/ns/bde/1.0/BasicComponents":
CreationDateTime}' is expected.
Parse succeeded (0.12) with 1 error and no warnings.
############################################################
Validating simpleExampleExtension.xml
############################################################
============== Phase 1: XSD schema validation ==============
No schema validation errors.
============ Phase 2: XSLT code list validation ============
No code list validation errors.
############################################################
Validating simpleExampleDecrypt.xml
############################################################
============== Phase 1: XSD schema validation ==============
No schema validation errors.
============ Phase 2: XSLT code list validation ============
No code list validation errors.
############################################################
Validating simpleExampleMultipleToPartyXMLEnc1.xml
############################################################
============== Phase 1: XSD schema validation ==============
No schema validation errors.
============ Phase 2: XSLT code list validation ============
No code list validation errors.
############################################################
Validating simpleExampleSignedNotFinal.xml
############################################################
============== Phase 1: XSD schema validation ==============
No schema validation errors.
============ Phase 2: XSLT code list validation ============
No code list validation errors.
############################################################
Validating simpleExampleSignedFinal.xml
############################################################
============== Phase 1: XSD schema validation ==============
No schema validation errors.
============ Phase 2: XSLT code list validation ============
No code list validation errors.
############################################################
Validating simpleExampleSignedNotFinalAdditional.xml
############################################################
============== Phase 1: XSD schema validation ==============
No schema validation errors.
============ Phase 2: XSLT code list validation ============
No code list validation errors.
############################################################
Validating simpleExampleSignedFinalAdditionalFail.xml
############################################################
============== Phase 1: XSD schema validation ==============
No schema validation errors.
============ Phase 2: XSLT code list validation ============
No code list validation errors.
val $
The test script invokes the validation script using the following::
-
in Windows:
validate.bat schema-file instance-file -
in shell:
sh validate.sh schema-file instance-file
The validation script invokes the schema script using the following:
-
in Windows:
w3cschema.bat schema-file instance-file -
in shell:
sh w3cschema.sh schema-file instance-file
The validation script invokes the XSLT script using the following:
-
in Windows:
xslt.bat instance-file stylesheet-file output-file -
in shell:
sh xslt.sh instance-file stylesheet-file output-file
The empty stylesheet BDE-DefaultDTQ-1.1.xsl is a placebo that would be
replaced with an XSLT stylesheet imposing value validation constraint checking on a
given instance of a business document envelope.
Appendix E Encrypting payloads to multiple recipients (Non-Normative) [comment?]
The BDE supports sending business documents to multiple recipients using a single envelope, which is obtained by adding multiple instances of the ToParty element to the BDE envelope.
When encrypting payloads of envelopes with multiple recipients, users SHOULD make use of encryption technologies that support multiple recipients so that an encrypted payload to multiple recipients can be contained in a single instance of a BDE envelope's PayloadContent. Examples of encryption technologies supporting multiple recipients are [CMS], [PGP] and [XMLEnc].
The workings of individual encryption technologies and methodologies are beyond
the scope of this specification, however an example of using [XMLEnc] with multiple
recipients has been included in the val/
subdirectory.
Appendix F Acknowledgements (Non-Normative) [comment?]
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
| Jens Aabol, Difi-Agency for Public Management and eGovernment |
| Oriol Bausa Peris, Individual |
| Kenneth Bengtsson, Alfa1lab |
| Erlend Bergheim, Difi-Agency for Public Management and eGovernment |
| Kees Duvekot, RFS Holland Holding B.V. |
| Sander Fieten, Individual |
| G. Ken Holman, Crane Softwrights Ltd. |
| Ole Madsen, Danish Agency for Digitisation, Ministry of Finance |
| Sven Rasmussen, Danish Agency for Digitisation, Ministry of Finance |
Appendix G Temporary Change Log [comment?]
This temporary change log will be removed in the final version of the committee specification.
| Revision | Date | Editor | Changes made |
|---|---|---|---|
| csd01wd01 | 06 November 2015 | GKH | Initial version of 1.1 with additional business objects |
| csd01 | 11 November 2015 | GKH | First version of CSD01 dated for upcoming 25 November 2015 meeting |
| csprd01 | 30 March 2016 | GKH | Public review draft of CS01 |
| csd02 | 07 July 2016 | GKH | Change ToParty to "1..n"; move XAdES imports into extension content data type |
| csd02 | 08 July 2016 | GKH | Added Kenneth's annex regarding encrypting payloads to multiple recipients |
| csprd02 | 20 July 2016 | GKH | Second public review draft of CS01 |