Agreement Formation Description Documents

Agreement Formation Description Documents

Working Draft 0.2

28 December 2008

Specification URIs:

This Version:

ebxml-cppa/afdd/v0.1/afdd.pdf

Previous Version:

Latest Version:

Technical Committee:

OASIS ebXML Collaboration Protocol Profile and Agreement (CPPA) TC

Chair(s):

Dale Moberg, Axway, <

Editor(s):

Pim van der Eijk, Sonnenglanz Consulting,

Related work:

This specification is related to:

OASIS ebXML Collaboration Protocol Profiles and Agreements version 2.0.
W3C XML Schema

Declared XML Namespace(s):

Abstract:

This specification defines the Agreement Formation Description Document type (AFDD), an XML language to identify and customize the multiple agreement documents used to set up and control the exchange of business documents. AFDD can be used with multiple XML-based agreement document types including XML schema, WSDL, and ebXML CPP and CPA. Itsupports both template-based and specialized formation methods, and binary as well as multi-party collaboration. AFDD covers agreement on (and customization of) business document payload schemas and vocabularies as well as message service configuration.

Status:

This document was last revised or approved by the OASIS ebXML Collaboration Protocol Profiles and Agreements TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at

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 (

The non-normative errata page for this specification is located at

Notices

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 OR 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, to 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 names "OASIS", [insert specific trademarked names and abbreviations here] are trademarks 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 for above guidance.

Table of Contents

1Introduction

1.1 Agreement Documents

1.2 Goals

1.3 Non-Goals

1.4 Requirements

1.5 AFDD Application Areas

1.6 AFDD and ebXML

1.7 Namespaces

1.8 Terminology

1.9 Normative References

1.10 Non-Normative References

2Agreement Formation Description Documents

2.1 AFDD Schema

2.2 NamespaceSets

2.3 Documents

2.3.1 XMLDocument

2.3.2 CollaborationProtocolAgreement

2.4 Agreement Formation

2.4.1 DocumentTransformation

2.4.2 CollaborationProtocolProfileIntersection

2.4.3 Bindings

2.4.4 Bindings and Parameter values

2.5 PartnerRoles

2.5.1 Partner

2.5.2 Parameter

3Conformance

3.1 “Document Transformer only” Conformance

3.2 Full Conformance

A.AFDD Schema

B.Implementing DocumentTransformation

B.1 Two stage transformation

B.2 Compiler Source Code

B.3 Parameter Exchange Schema

C.Customizing UBL Invoice Exchange

C.1 Sample AFDD

C.2 XSLT stylesheet for CPA template

C.3 Parameters

C.3.1 Seller

C.3.2 Buyer

D.Revision History

Agreement Formation Description Documents Technical Specification23 December 2008

1Introduction

1.1Agreement Documents

To achieve interoperability, organizations that exchange business documents using electronic messages need to agree on a range of aspects including business document syntax and semantics, business process and choreography, quality of service, communication parameters, security settings, message protocol configuration and commercial and legal requirements. Agreements can be expressed in human-oriented documentation or in a machine-processable form that permits automated interpretation.

In a typical environment there are often multiple agreement documents. Some of these documents are:

Document structure definitions and vocabularies. If formally expressed, these are usually based on XML Schema [XSD] or other schema languages. An example XSD is the Invoice schema [UBL Invoice]in the OASIS Universal Business Language (UBL) standard [UBL].
Profiles customizing such document schemas and vocabularies to specific geographies, industries, assumed level of automation or even to specific trading partners. An example profile is the profile 6 of the OASIS UBL invoice in the Northern European Subset (NES) of UBL [NES 2.0]. Profiles typically eliminate optional elements or groups, constrain cardinality and restrict value sets or types. Profiles are often expressed in natural language as implementation guidelines. Sometimes they are defined more formally as constrained XML schemas or as ISO Schematron [ISO 19757-3] rulesets.
Code-lists (also known as coded value enumerations). Some code-lists are static and provided in the XML schema but others are highly dynamic and usually managed separately.
Service definitions (partner profiles) using languages such as Web Service Description Language [WSDL]or the ebXML Collaboration Protocol Profile [CPPA 2].
Service contractsexpressed in languages such as the ebXML Collaboration Protocol Agreements [CPPA 2].
Message choreography expressed in languages like the ebXML Business Process [ebBP 2].

In service-oriented architecture, these agreements are typically referred to as service contracts[SOA-RM].

1.2Goals

The AFDD specification aims to define a simple XML-based language that:

Identifies the agreement documents that need to be agreed upon to establish a business collaboration of some specific type.
Identifies (by role) the business partners that participate in such a business collaboration.
Identifies the parameters that the business partners must (or may) provide and their bindings into the agreement documents
Covers the common scenario where agreements are largely fixed,except for a limited set of partner-provided parameters (template-based agreement formation).
Is extensible to specialized agreement formation.
Covers both customization of business payloads and message configuration.

1.3Non-Goals

The following are out of scope for (this version of) AFDD:

Complex agreement formation where an agreement cannot be established automatically based on partner-provided inputs but requires some additional message exchanges (offer, counter-offer) and/or human intervention to establish the agreement.
Message protocols for exchanging parameter information electronically.

1.4Requirements

The following identifies some key driving requirements:

Neutrality with respect to the actual agreement languages, as long they are XML based.
Support for template-based agreement formation.
Clear separation of what may or must be configured and what is not configurable.
Extensibility to support other agreement formation methods (such as CPP intersection)
Support multiple agreement documents and more than two business partners in a collaboration

1.5AFDD Application Areas

AFDD can be used as a definition language for template-based agreement formation that formally defines both fixed (in the template) and variable (partner-configurable) parameters. AFDD documents can also be interpreted to generate computer programs that automatically generate (an) agreement document(s) based on template(s) and partner-provided parameters. Appendix B provides a sample XSLT-based implementation of an AFDD compiler which supports one such agreement method, DocumentTransformation.

AFDD-derived software that forms agreement documents could also use a (properly secured) Web portal to allow business partner to provide parametersusing a self-service model. In a portal, the afdd:Partner definitions could be used to generaterole-specific HTML forms, or partners could upload their parametersets in an XML or other format. Non-normative section B.3 provides one such XML format.

Alternatively, electronic messages could be used to exchange these parameters across networks, e.g. using the proposed profile exchange messaging extension of the IETF Certificate Exchange Message [CEM] or using a custom protocol based on ebXML messaging ([ebMS 2.0] or [ebMS 3.0]).

1.6AFDD and ebXML

AFDD is neutral with respect to agreement document formats and can be used to describe and establish agreements in environments that do not use any ebXML-specific technology. One such application area is simple customization of XML business documents schemas.

However, AFDD does intend to support configuration of ebXML-based collaborations well. AFDD can describe formation of ebXML Collaboration Protocol Agreement (CPA) documents using either the DocumentTransformation method (template-based formation) or via the specialized CollaborationProtocolProfileIntersectionmethod. A non-normative reference implementation of template-based formation is provided in appendixB and the sample AFDD in appendix C.1 applies this to formation of a CPA and a constrained XML schema for UBL-based e-invoicing.

As AFDD supports multiple agreement documents and more than two business partners, it can be used to instantiate business collaborations in complex business chains or trading networks, provided the communication of each pair of partners can be configured by at least one agreement document (such as a CPA template). The ebXML Business Process specification [ebBP 2] supports multi-party collaborations. Such collaborations can be associated with AFDD documents that identify all business partners and the agreement documents to be configured to support such multi-party collaborations.

1.7Namespaces

This specification and/or examples used in it reference the following namespaces:

Prefix / Namespace / Specification
afdd / / This document
cac / Urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2 / [UBL Invoice]
cpa2 / / [CPPA 2]
cpa3 / / [CPPA 3]
cpa / Used ambiguously to generalize over elements present in both version 2.0 and 3.0 of ebXML CPA. / [CPPA 2] or
[CPPA 3]
ubl2 / urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 / [UBL]
xsd / / [XSD]

1.8Terminology

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 [RFC2119].

1.9Normative References

[RFC2119]S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997.

[CPPA2]OASIS Standard. Collaboration-Protocol Profile and Agreement Specification Version 2.0, September 2002.

[ebBP 2]OASIS Standard.ebXML Business Process Specification Schema Technical Specification v2.0.4.

[ISO 19757-3]ISO/IEC 19757-3:2006. Information technology -- Document Schema Definition Language (DSDL) -- Part 3: Rule-based validation – Schematron

[SOA-RM]OASIS Standard. Reference Model for Service Oriented Architecture 1.0 October 2006.

[URI]T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, MIT/LCS, Day Software, Adobe Systems, January 2005.

[WSDL]W3C Note. Web Services Description Language (WSDL) 1.1. Mach 2001.

[XML-DSIG]W3C Recommendation. XML Signature Syntax and Processing (Second Edition). June 2008.

[XPATH]W3C Recommendation. XML Path Language (XPath) 2.0. January 2007.

[XSD]W3C Recommendation, "XML Schema Part 1: Structures Second Edition", 28 October 2004.

[XSLT]W3C Recommendation. XSL Transformations (XSLT).Version 2.0. January 2007.

1.10Non-Normative References

[CEM]IETF Draft. Certificate Exchange Messaging for EDIINT.

[CPPA 3]OASIS Working Draft. Collaboration-Protocol Profile and Agreement Specification. Version 3.0. 2009..

[ebMS 2.0]OASIS Standard. OASIS ebXML Message Service Specification. Version 2.0, April 2002.

[ebMS 3.0]OASIS Standard. OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features

[Genericode]OASIS Committee Specification.Code List Representation (Genericode). Version 1.0. December 2007.

[NES 2.0]Northern European Subset (NES) for OASIS Universal Business Language (UBL) Profile 6: Basic Procurement.

[UBL]OASIS Standard. Universal Business Language v2.0. December 2006.

[UBL Invoice]XML schema for the Invoice business document type.

2Agreement Formation Description Documents

This section defines the AFDD XML schema syntax and semantics.

2.1AFDD Schema

The structure of Agreement Formation Description Documents is defined normatively by the AFDD schema, which defines the following namespace:

The schema will become available from the following location at the OASIS site:

The root element of an AFF document is the AgreementFormationDescriptionDocument element. This element is of type AgreementFormationDocumentTypeand establishes a relation between one or multiple business agreement Documents and two or more PartnerRoles. The element has a name and a version.

Figure 1 AgreementFormationDescriptionDocument

2.2NamespaceSets

Agreement documents are XML documents that each have their own XML namespace and often import elements and types from other XML namespaces. As afdd:Binding elements have pattern-based references into agreement documents, they need to include namespace prefixes that reference these namespaced elements. The afdd:NamespaceSets container provides a central and reusable grouping for definitions of namespaces and namespace prefixes that can be used in defining agreement documents. It is of type afdd:NamespaceSetsTypeand contains one or more afdd:NamespaceSet elements.

Figure 2 NamespaceSetsType

An afdd:NamespaceSet of type afdd:NamespaceSetType consists of a series of afdd:ns elements. A namespace set can be uniquely identified by its name attribute.

Figure 3 NamespaceSetType

An afdd:ns element associates a namespace prefix to a namespace uri.

A non-normative example of a namespace set is the following example which can be used to customize UBL 2.0 schemas:

<afdd:NamespaceSet name="ubl2">

<afdd:ns prefix="xsd" uri="

<afdd:ns prefix="ccts" uri="urn:un:unece:uncefact:documentation:2"/>

<afdd:ns prefix="udt"

uri="urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2"/>

<afdd:ns prefix="qdt"

uri="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDatatypes-2"/>

<afdd:ns prefix="cbc"

uri="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"/>

<afdd:ns prefix="ext"

uri="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"/>

<afdd:ns prefix="cac"

uri="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"/>

</afdd:NamespaceSet>

2.3Documents

The Documents element is a container for one or more elements of type DocumentType. DocumentType is an abstract base type for the subtypes XMLDocumentType and CollaborationProtocolAgreementType. These subtypes have specific content models and subtype-specific formation methods. Future versions of AFDD or derivative specifications MAY extend the functionality of this specification by providing additional document types with specialized formation methods.

The requiredid attribute provides a unique identifier for an agreement document. This value MAY be used in AFDD software to identify which agreement document a particular (generated) component refers to. For instance, AFDD software that generates XSLT scripts for each DocumentTransformation method MAY use the value of the attribute for stylesheet naming.

2.3.1XMLDocument

The element XMLDocument of type XMLDocumentType covers any business agreement document that uses an XML notation and that can be manipulated using XML technologies such as XSL transformations[XSLT]. This includes document schema files based on W3C XML Schema [XSD]or other schema languages.