Ebxml Business Process Specification Schema V2.0.1 (Ebbp)

ERRATA v2.0.4

ebXML Business Process Specification Schema Technical Specification v2.0.4

Errata, 19 June4 September2006

DocumentIdentifier:

ebxmlbp-v2.0.4-Errata-cdwd-r02-en-diff.doc

OASIS Identifier:

To be assigned

Location:

Current: (public location)

This Version:See Current.

Previous Version:

Artifact Type:

Errata

Technical Committee:

ebXML Business Process Technical Committee

Co-chairs:

Dale Moberg, Cyclone Commerce/Axway

Monica J. Martin, Sun Microsystems

Editors:

Monica J. Martin, Sun Microsystems,

Contributors:

Dale Moberg, Cyclone Commerce/Axway, co-chair, <>

Monica J. Martin, Sun Microsystems, co-chair,

Related Work:

See references in Section 1.4.

Abstract:

This document defines any errata for ebBP, a standards-based business process foundation that promotes the automation and predictable exchange of Business Collaboration definitions using XML.

Status:

This errata complements the relevant packages identified for the ebBP version specified.

The ebXML Business Process TC charter including scope is found at:

Committee members should send comments on this specification to the list. Others should subscribe to and send comments to the list. To subscribe, send an email message to with the word "subscribe" as the body of the message.

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 ebXML Business Process TC web page ( The IPR policy in effect as of 19 June4 September 2006 is the Legacy IPR policy.

Document Metadata:

Owner: ebxml-bp (OASIS ebXML Business Process TC)

Product: ebxmlbp (aka ebBP)

Product Version: 2.0.4

Artifact Type: Errata

Stage: wdcd

Descriptive Name: None required

Revision: Noner02 (diff)

Language: en (English)

Form: .doc

Date: 20060619 20060904 (19 June4 September 2006)

Notices

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.

Copyright © OASIS Open 2005, 2006. All Rights Reserved.

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.

Table of Contents

ebXML Business Process Specification Schema Technical Specification v2.0.4..1

1.1Terminology...... 6

1.2Summary of Contents of Document...... 6

1.3Audience...... 6

1.4Related Documents...... 6

1.5Normative References...... 6

1.6Non-Normative References...... 6

2Errata Overview...... 7

3Errata...... 8

3.1Technical Specification Errata...... 8

3.1.1Editorial Reference Errata...... 8

3.1.2Process Definition Example Errata...... 9

4Errata Revision History...... 11

ebXML Business Process Specification Schema Technical Specification v2.0.4

1.1Terminology

1.2Summary of Contents of Document

1.3Audience

1.4Related Documents

1.5Normative References

1.6Non-Normative References

2Errata Overview

3Errata

3.1Technical Specification Errata

3.1.1Editorial Reference Errata

3.1.2Process Definition Example Errata

3.1.2.1Process Definition Example Errata, Section 3.4.6.3

3.1.2.2Process Definition Example Errata, Section 3.4.10.2

3.1.2.3Process Definition Examples Errata, Section 3.4.11.2

1Introduction
Introduction

This errata document identifies changes to the identified version of the ebXML BPSS, the eBusiness eXtensible Markup Language (ebXML) Business Process Specification Schema (BPSS) as specified in Section 1.4.

Implementation Note:

Throughout this document, shorthand is used. The technical specification is referenced as the ebBP technical specification. An ebBP business process definition is identified as an ebBP definition. An ebXML BPSS instance is an ebBP instance. An ebXML BPSS schema is an ebBP schema.

1.1Terminology

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optionalin this document are to be interpreted as described in [RFC 2119]. These provide indications as to normative capabilities defined in this technical specification.

1.2Summary of Contents of Document

This document describes anyerrata to the ebBP technical specification as specified.

1.3Audience

The primary audience is business process analysts. We define a business process analyst as someone who interviews business people and as a result documents business processes in unambiguous syntax.

An additional audience is designers of business process definition tools who need to specify the conversion of user input in the tool into the XML representation of the ebBP artifacts.

1.4Related Documents

This errata document relates to:

• ebBP technical specification, version 2.0.3, Committee Specification approved 28 April 2006

Unless otherwise specified, these changes are non-substantive changes to the documents identified.

1.5Normative References

Normative references are held in the latest or appropriately referenced ebBP technical specification unless revised herein. Please refer to the appropriate document(s).

1.6Non-Normative References

Non-normative references are held in the latest or appropriately referenced ebBP technical specification unless revised herein. Please refer to the appropriate document(s).

ebxmlbp-v2.0.4-Spec-Errata-cd-enwd-r02-en-diff19 June4 September 2006

Copyright © OASIS Open 2005, 2006. All Rights Reserved.Page 1 of 14

ERRATA v2.0.4

2Errata Overview

ebBP definitions describe interoperable business processes that allow business partners to collaborate and achieve a given business goal. This errata identifies changes relevant to an implementer, user community or partner interested in or using the ebBP technical specification and packages.

3Errata

The ebBP technical specificationdefines a standard language for business process specification. This errata is to be used with the set of ebBP approved packages. Any errata changes are indicated in bold underlined text.

3.1Technical Specification Errata

3.1.1Editorial Reference Errata

Any errata changes are indicated in bold underlined text. Two minor references should be editorially updated in the following sections:

1. Figure Reference for Section 2.4.5: “Although independent, the ebXML components are designed to work together in a loosely coupled fashion. At a minimum, the ebXML Registry/Repository could allow the discovery and use of ebBP instances. If artifacts are given a classification, the instances and the profiles of the BT patterns could be part of a business process catalogue. They may be available to an industry group, enterprise or entity. The ebXML Registry/Repository provides the capability to version and manage such artifacts (See preceding figure and a similar one in Section 3).”
2. Reference for Section 3.4.10.1: “As described later in Section 3, these linking constructs, or movements between states (which were previously called pseudo-states), would be Start, CompletionState (and sub-specializations of that, Success and Failure), Fork, Join, Decision (or Choice), and Transition. They correspond to bundles of labeled edges of a directed possibly cyclic graph. At their core, they are collections of pairs of nodes, and describe the potential paths of a ebBP definition.”

3.1.2Directory Reference Errata

In compiling and deploying the existing packages for the ebBP v2.0.3, a limitation was found in the use of namespaces and directories, given existing tools. Therefore, an update was required to work around these tool limitations and alleviate using the URI for a namespace and directory. Actual directory changes were coordinated with OASIS administration and support. Therefore, the resolution is as follows, for interested implementers and user communities in Section 2.1.

“The ebBP technical specification is available as an XML Schema ( The ebBP XML schema, that provides the specification for XML based ebBP definitions, can be found at this location:

(schema: ebbp-2.0.3.xsd)”

“The ebBP XML signal schema can be found at this location:

(signal schema: ebbp-signals-2.0.3.xsd)“

These resolve as follows, respectively:

.

Therefore, an explanatory note will be added to the specification as follows in Section 2.1:

“The ebBP technical specification is available as an XML Schema ( The ebBP XML schema, that provides the specification for XML based ebBP definitions, can be found at this location:

(schema: ebbp-2.0.3.xsd)”

“The ebBP XML signal schema can be found at this location:

(signal schema: ebbp-signals-2.0.3.xsd)

In order to accommodate varying tool capabilities surrounding namespaces and directories using URIs, the URI for each schema has been updated. Current URI paths are found on the OASIS ebBP public web site at:

Under “’Technical Work Produced by the Committee’”

The details explained in this section will be documented at that location.

3.1.3Process Definition Example ErrataProcess Definition Example Errata

The following examples are updated as specified, and the same criteria as required in the technical specification should be followed. All examples in the ebBP technical specification are non-normative and exemplary in nature. In cases where specifics in an example have been deleted, comments are added here. However, these comments will be deleted when integrated into the succeeding technical specification.

3.1.3.1Process Definition Example Errata, Section 3.4.6.3

In Section 3.4.6.3, an exemplary use of the XInclude functionality was commented away. The example is hereby updated, and the same criteria as required in the technical specification should be followed. All examples in the ebBP technical specification are non-normative and exemplary in nature.

<ProcessSpecification

xmlns="

xmlns:xsi="

xmlns:xi="

name="PurchasingCluster" nameID="PC23"

uuid="urn:purchasingcluster" specificationVersion="2"

instanceVersion="1">

<xi:include href="signals-package-2.0.3.xml" parse="xml"

xpointer="element(/1/1)"/>

<BusinessDocument name="Invoice" nameID="bd-invoice">

<!--Shows use of externalDocumentDefRef optional attribute-->

<Specification type="schema"

location="ubl-1-0-SBS-cs/xpaths/xml/XPath/Invoice-XPath.xml"

targetNamespace="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0"

name="Invoice" nameID="invoice32”

externalDocumentDefRef=”urn:oasis:names:tc:ubl:xpath:Invoice-1.0:sbs-1.0"/>

</BusinessDocument>

<BusinessDocument name="InvoiceResponse"

nameID="bd-invoiceResponse">

<Specification type="schema"

location="

name="InvoiceResponse" nameID="invoice33"/>

</BusinessDocument>

<DataExchange name="Data:Invoice" nameID="data-invoice">

<RequestingRole name="DIinitiator" nameID="DIinitiator1"/>

<RespondingRole name="DIresponder" nameID="DIresponder1"/>

<RequestingBusinessActivity name="ReqBA:SendInvoice"

nameID="debareq-invoice"

timeToAcknowledgeReceipt="PT6H"

timeToAcknowledgeAcceptance="PT12H">

<DocumentEnvelope name="DE:ProcessInvoice"

nameID="data-de-invoice" businessDocumentRef="bd-invoice"/>

</RequestingBusinessActivity>

<RespondingBusinessActivity name="ResBA:ReceiveInvoice"

nameID="debares-invoice">

<DocumentEnvelope name="DE:ProcessInvoiceResponse"

nameID="data-de-invoiceResponse"

businessDocumentRef="bd-invoiceResponse"/>

</RespondingBusinessActivity>

</DataExchange>

<BusinessTransaction name="BT:Invoice" nameID="bt-invoice">

<RequestingRole name="INinitiator" nameID="INinitiator1"/>

<RespondingRole name="INresponder" nameID="INresponder1"/>

<RequestingBusinessActivity name="ReqBA:SendInvoice"

nameID="reqba-invoice"

timeToAcknowledgeReceipt="PT6H"

timeToAcknowledgeAcceptance="PT12H">

<DocumentEnvelope name="DE:ProcessInvoice"

nameID="bt-de-invoice" businessDocumentRef="bd-invoice"/>

<ReceiptAcknowledgement name="sira" nameID="sira1"

signalDefinitionRef="ra2"/>

<ReceiptAcknowledgementException name="sirae"

nameID="sirae1" signalDefinitionRef="rae2"/>

</RequestingBusinessActivity>

<RespondingBusinessActivity name="ResBA:ReceiveInvoice"

nameID="resba-invoice">

<DocumentEnvelope name="DE:ProcessInvoiceResponse"

nameID="bt-de-invoiceResponse"

businessDocumentRef="bd-invoiceResponse"/>

<ReceiptAcknowledgement name="sira" nameID="sira2"

signalDefinitionRef="ra2"/>

<ReceiptAcknowledgementException name="sirae"

nameID="sirae2" signalDefinitionRef="rae2"/>

</RespondingBusinessActivity>

</BusinessTransaction>

</ProcessSpecification>

3.1.3.2Process Definition Example Errata, Section 3.4.10.2

In Section 3.4.10.2, an exemplary use of choreography and state transitions is shown. An update has been provided to increase understanding of interested user communities for these functionalities. This example shows a start and two possible outcomes of this collaboration, Success and Failure. The Transition element is not needed because the Start has a ToLink (as required). In addition, the ID value in fromBusinessStateRef is not the ID value of the BusinessTransactionActivity (BTA) in the choreography.

<BusinessCollaboration name="Firm Order" nameID="ID122A38D93">

<Role name="buyer" nameID="ID122A38DA3"/>

<Role name="seller" nameID="ID122A38DA5"/>

<TimeToPerform duration="P1D"/>

<Start name="ID876F38OP5" nameID="ID876F38OP5">

<ToLink toBusinessStateRef=" IDPO3DA1"/>

</Start>

<BusinessTransactionActivity name="Place Order" nameID="IDPO3DA1"

businessTransactionRef="ID122A3DD33" hasLegalIntent="true">

<TimeToPerform duration="PT4H"/>

<Performs currentRoleRef="ID122A38DA3" performsRoleRef="CCinitiator1"/>

<Performs currentRoleRef="ID122A38DA5" performsRoleRef="CCresponder1"/>

</BusinessTransactionActivity>

<Success name="Success" nameID="D2JSK99AK"/>

<Failure name="Failure" nameID="DK9726AJ"/>

<Decision>

<FromLink fromBusinessStateRef=" IDPO3DA1"/>

<ToLink toBusinessStateRef=" D2JSK99AK">

<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Success"/>

</ToLink>

<ToLink toBusinessStateRef="DK9726AJ">

<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Failure"/>

</ToLink>

!-- Deleted transition-->

</Decision>

</BusinessCollaboration>

3.1.3.3Process Definition Examples Errata, Section 3.4.11.2

In Section 3.4.11.2, that Business Collaboration adds choreography in the example. An addition BTA for a credit check has been included to make the example more useful for implementers. Note that a Role is added for the credit authority also. The ID values used in the new BTA occur in other examples.

<BusinessCollaboration name="Firm Order" nameID="ID122A38D93">

<Role name="buyer" nameID="ID122A38DA3"/>

<Role name="seller" nameID="ID122A38DA5"/>

<Role name="creditauthority" nameID="ID122A38DA7"/>

<TimeToPerform duration="P1D"/>

<Start name="ID876F38OP5" nameID="ID876F38OP5">

<ToLink toBusinessStateRef="ID122A39C23"/>

</Start>

<BusinessTransactionActivity name="Place Order" nameID="ID122A39C23"

businessTransactionRef="ID110" hasLegalIntent="true">

<TimeToPerform duration="PT4H"/>

<Performs currentRoleRef="ID122A38DA3" performsRoleRef="ID122A3E833"/>

<Performs currentRoleRef="ID122A38DA5" performsRoleRef="ID122A3E863"/>

</BusinessTransactionActivity>

<BusinessTransactionActivity name="Check Credit" nameID="ID122A39D24"

businessTransactionRef=" ID122A3DD33" hasLegalIntent="true">

<TimeToPerform duration="PT4H"/>

<Performs currentRoleRef="ID122A38DA5" performsRoleRef="CCinitiator1"/>

<Performs currentRoleRef="ID122A38DA7" performsRoleRef="CCresponder1"/>

</BusinessTransactionActivity>

<Success name="Success" nameID="D2JSK99AK"/>

<Failure name="Failure" nameID="DK9726AJ"/>

<!-- Deleted transition-->

<Decision>

<FromLink fromBusinessStateRef="ID122A39C23"/>

<ToLink toBusinessStateRef="ID122A39D24">

<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Success"/>

</ToLink>

<ToLink toBusinessStateRef="DK9726AJ">

<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Failure"/>

</ToLink>

</Decision>

<Decision>

<FromLink fromBusinessStateRef="ID122A39D24"/>

<ToLink toBusinessStateRef="D2JSK99AK">

<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Success"/>

</ToLink>

<ToLink toBusinessStateRef="DK9726AJ">

<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Failure"/>

</ToLink>

</Decision>

</BusinessCollaboration>

Also in Section 3.4.11.2, the variable example is also updated in order for the variables belong to the expressionLanguage value of the ConditionExpression used in assigning the Variable value.

<Variable name="PO Accepted" nameID="H7YIUSOP" businessTransactionActivityRef="ID122A39C23" businessDocumentRef="ID1012">

<ConditionExpression expressionLanguage="XPath1" expression="//POAck[@status=’Reject’]"/>

</Variable>

…

<Decision name="Decision10" nameID="IDDecision10">

<FromLink fromBusinessStateRef="ID122A39C23"/>

<ToLink toBusinessStateRef="ID122A39D24" >

<ConditionExpression expressionLanguage="XPath1” expression="PO Accepted" />

<!—Updated expressionLanguage -->

</ToLink>

<ToLink toBusinessStateRef="DK9726AJ" >

<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Failure"/>

</ToLink>

</Decision>

4Errata Revision History

The revision history for any errata related to the ebBP set of packages is provided.

1. Non-normative changes for examples
2. Non-normative change related to directory enhancements found in conjunction with OASIS that may affect other TCs

ebxmlbp-v2.0.4-Errata-cd-enwd-r02-en-diff19 June4 September 2006

Copyright © OASIS Open 2005, 2006. All Rights Reserved.Page 1 of 14