xCBL Document Creation Methodology

version 1.0

last updated on:
07/11/02

Introduction
1.1.	Business Process or Document?
1.2.	Roles
2.	Overview of Process
3.	Initial Contact
3.1.	Description/purpose of the step
3.2.	Requestor responsibility to execute this step
3.3.	Deliverable(s) associated with this step
3.4.	Commerce One action for this step
3.5.	Criteria for the next step
4.	Define Exchange Requirements
4.1.	Description/purpose of the step
4.2.	Requestor responsibility to execute this step
4.3.	Deliverable(s) associated with this step
4.4.	Commerce One action for this step
4.5.	Criteria for the next step
4.6.	Public Vs. Proprietary Document
5.	Define the Business Process
5.1.	Description/purpose of the step
5.1.1.	Business Transactions
5.1.2.	OrderCreateAndSingleOrderResponse example
5.1.3.	Choreography
5.2.	Requestor responsibility to execute this step
5.3.	Deliverable(s) associated with this step
5.4.	Commerce One action for this step
5.5.	Criteria for the next step
6.	Research External Requirements
6.1.	Description/purpose of the step
6.2.	Requestor responsibility to execute this step
6.3.	Deliverable(s) associated with this step
6.4.	Commerce One action for this step
6.5.	Criteria for the next step
7.	Identify Data for New Document
7.1.	Description/purpose of the step
7.2.	Requestor responsibility to execute this step
7.3.	Deliverable(s) associated with this step
7.4.	Commerce One action for this step
7.5.	Criteria for the next step
8.	Review and Revise
8.1.	Description/purpose of the step
8.2.	Requestor responsibility to execute this step
8.3.	Deliverable(s) associated with this step
8.4.	Commerce One action for this step
8.5.	Criteria for the next step
9.	Finalize and Build
9.1.	Description/purpose of the step
9.2.	Requestor responsibility to execute this step
9.3.	Deliverable(s) associated with this step
9.4.	Commerce One action for this step
9.5.	Criteria for the next step
10.	Appendix
10.1.1.	Document Determination Process
10.1.2.	Business Process Definition
10.1.3.	Related Standards
10.1.4.	Registration Form -Intent To Develop a XML Business Process or Document
Notes
Comments

Introduction

The xCBL Document Creation methodology specification is a resource for individuals or companies looking to create new Business Documents based on xCBL.  This specification details the process and steps needed to create and introduce new business documents to the library of existing xCBL documents in support of electronic commerce.  By following the methodology outlined in this specification, a new document can be requested and created that will fill the needs of either the entire Global Trading Web or specific application requirements.  The addition of a new document to the xCBL library is not limited to members of the Global Trading Web (GTW).

The goal of this specification is to educate trading partners on the process of document creation, thus enabling them to participate in the process of generating new xCBL documents in an effective and timely manner.  

The methodology outlined here serves to create new business documents that can be included in xCBL as well as creation of documents that are based on xCBL building blocks but are not specifically targeted for inclusion in xCBL.  Additionally, this methodology covers the process a trading partner will go through to determine if an existing xCBL document can meet their needs or be extended to cover their business process need.

The requestor of a new document should be familiar with the contents of the xCBL website, the Sox Tutorial, and xCBL Development Resources.

1.1.	Business Process or Document?

Ideally the creation of a new xCBL document would be based on an analysis of a business process.  The analysis of the business process would define the requirements of the new document.  Once the requirements have been defined, they can then be turned into a new xCBL document.  Fortunately or unfortunately, this is not always the case.  There do exist EDI and XML standards that a requestor may want to recreate using the xCBL structure.  A Requestor may have a document in an EDI format and they now want the document in an xCBL format.  So does a user ignore business process because they feel that they can simply port over an existing standard?  Hopefully not, there is still a need to define the process in which the document will be used.   The business process may drive out additional requirements not included in the current EDI document, or it may prove that certain parts of the EDI document are not needed to support the business process that the new xCBL document is created to support. 

1.2.	Roles

This methodology outlines roles and responsibilities of both the requestor and Commerce One Document Engineering.  
•	The requestor can be any individual who has a need for an xCBL document to be created to support a business process.  
•	Document Engineering is a department within Commerce One responsible for the creation and maintenance of xCBL.  They are the experts on xCBL and are a valuable resource to the requestor of the document.  Document engineering can play various roles within the process: 
o	Review information from requestor
o	Review and Help requestor at various steps
o	Create Document with input from requestor

This methodology is written from the point of view that the requestor will identify the need for a document, define requirements and then finally create the document.  This may or may not be the case for the way that a new document may be created.  At the time of the initial request, Document Engineering may decide to work with the requestor and have Document Engineering create the new xCBL document.  In other cases, the requestor may perform up to a certain step and then have Document Engineering take over to complete the steps with input from the requestor.  There is no defined path on who will perform what activity, or the level of involvement from either party.  The level of involvement from either role depends on a number of factors:  knowledge of xCBL, knowledge of the business process, knowledge of the existing standards and generally overall capabilities.  In some cases it may be much better for the requestor to just provide input and advice and have Document Engineering perform the steps outlined throughout the methodology.

Each section of this document is broken down into five different areas:

1.	Description/purpose of the step
2.	Requestor responsibility to execute this step	
3.	Deliverable(s) associated with this step
4.	Commerce One action for this step
5.	Criteria for the next step

2.	Overview of Document Creation Process

•	The requestor of a new document will contact Commerce One Document Engineering with whatever requirements are available at the time.  
•	Document Engineering will review the request and determine if an existing document will meet the needs of the initial requirements.
•	Document Engineering will then provide the tools and contacts to enable the requestor to begin the process of developing the new document.  
•	The requestor will identify the service or application needing the new document and any other services or types of applications that may utilize the new document.  
•	The requestor will provide details on how the new document supports a given business process or processes.  
•	The requestor will identify transactions that the document will support and how this document may fit in with existing business transactions or collaborations. 
•	The Requestor will identify and document if the new document functionality requirements exist in other standard EDI or XML documents. 
•	The Requestor will identify which data sets are needed to support the requirements of the new document
•	The Requestor will submit above stated information to Document Engineering for review and collaborative revision.
•	The new document and associated documentation will be published for review.  The GTW and other interested parties will provide feedback that will be reviewed for possible incorporation into the document
•	New document will be finalized and built to be included in a specific release of xCBL.

3.	Initial Contact
3.1.	Description/purpose of the step

The requestor of a new document will gather as much information as possible regarding a new document and submit the request to Commerce One

The need for a new document can come from a variety of sources.  Primary sources for new documents are:
•	Existing members of the GTW
•	New members to the GTW
•	Potential members of the GTW
•	Service providers
•	Application requirements
3.2.	Requestor responsibility to execute this step	

When one of the above sources identifies the need for a new document, they will gather up the known functional requirements of the document.  The requestor determines if the functional requirements could be met by an existing xCBL document.  If they determine that the request cannot be met by and existing document they will then contact Commerce One Document Engineering using the Registration Form -Intent To Develop a XML Business Process or Document.  Some of the information required within the registration form may not be known at the time of the initial request and may be filled in at a later time.  

The requestor will identify the following information in the initial contact:
•	Name of requestor
•	Company requesting new document
•	Phone of requestor
•	Email of requestor
•	Confidential or public document
•	New document name
•	New Document purpose

3.3.	Deliverable(s) associated with this step
Registration Form -Intent To Develop a XML Business Process or Document.
3.4.	Commerce One action for this step

This information will be submitted to Commerce One Product Management and Document Engineering for initial review.  Document Engineering will review the request and determine if functional requirements can be met by existing xCBL document.  If Document Engineering believes that the request can be satisfied with an existing xCBL document, document engineering will contact requestor for review and or clarification.  If it is determined that the request cannot be satisfied with an existing xCBL document, Document Engineering will contact the requestor.  Product Management will review the request and determine if the document should be included in a public release of xCBL.

Document Engineering will review the process for new document development with the requestor and provide the tools for document creation.  
3.5.	Criteria for the next step

A determination has been made if a new document needs to be created or an existing document can be used or extended.

Product Management has decided if this type of document should be included in a future release of xCBL or if the requestor will create a proprietary document.

4.	Define Exchange Requirements
4.1.	Description/purpose of the step

Defining a new document includes determining the type and scope of applications that may use the new document.  Depending on the functional purpose of the document, the document may be utilized by many applications, services and exchanges.  Other documents may be very specific between two parties and not be of general use to the GTW.  This step will specify which applications, services or trading partners would use the new document.

4.2.	Requestor responsibility to execute this step

The requestor will identify and document the known requesting and responding applications / services of the new xCBL document.  The requestor may have a specific application or service in mind when they make the request for a new document.  They may also know of similar applications or services that could use the new xCBL document.  This information can also be documented on the Registration Form -Intent To Develop a XML Business Process or Document.  The requestor will include the following regarding the exchange requirements:

•	Name of the requesting application / service
•	Name of the responding application / service
•	Name of potential requesting application(s) / service(s)
•	Name of the potential responding application(s) / service(s)

By identifying the above stated information, the requestor will be able to determine if their request is very specific to their requirements or of general use to the GTW.  By identifying potential applications / services, integration efforts can be planned for applications / services to support the new document.  A document request will need to specify if the document is for general use or very specific to a given application or service

4.3.	Deliverable(s) associated with this step
Completion of the Registration Form -Intent To Develop a XML Business Process or Document

4.4.	Commerce One action for this step

Document engineering will review the applications and or services identified by the document requestor.  They will make a determination if there are any additional applications or services that should be included in the document creation process.  If the new document is intended to be for public use, efforts must be made to ensure that requirements of various applications / services are incorporated into the document definition.  Those interested parties will be given the opportunity to review the proposed document and provide input and or changes on the structure and content of the document.

Additionally, the various partners who may be interested in using the newly created document can plan testing efforts.

4.5.	Criteria for the next step

Registration form is completed

Services, applications and trading partners have been identified

Commerce One has agreed with the requestor on the use of the document and the scope of the document.  At this point there is a determination of whether the document will be public or proprietary  

4.6.	Public Vs. Proprietary Document

A Public document is a document that is developed to be open and support various industries and applications or services.  A proprietary document is used specifically between two trading partners or a closed trading community and is not intended to be for public use or is confidential.

Generally applicable documents that could be utilized by various trading partners and their particular services and application must be made open and usable for multiple parties.  For example, when defining an Invoice document, a requestor could limit their requirements of the document to only what their particular application needs to support the creation of an XML document.  This approach however is not consistent with the goal of interoperability and the existence of xCBL as a common business library.  Invoice is a widely used business document and should contain the data needed to support numerous applications or services, not just the requirements of the requesting party.  Due to the need for openness and interoperability, a requestor must determine if the given document may be utilized by more than just their requirement for a new document.  As part of the review process, Document engineering will review the request and determine the scope and audience of the new document request.

A trading partner however, may want to use the format of xCBL to use XML messaging with a new trading partner or service, and thus want a private message that will not be generally available.  There are three reasons for this:
•	Proprietary information that a given trading partner does not want to open up to the Global Trading Web
•	Application specific information that is not relevant to a larger community
•	Supports a confidential business process that is a competitive advantage for trading partners and does not want to disclose information

Document Engineering will review the request to determine if the document requirement can be extended to other applications or services, or if the requirement is truly unique or confidential to the two trading partners or trading community.  If the requirements prove to only meet the needs of the two trading partners then the document will not go out for public review.

5.	Define the Business Process

5.1.	Description/purpose of the step

Definition of the business process is fundamental to the creation of any new xCBL document.  A new xCBL document may introduce new business process support into the xCBL library or extend an existing business process.  The business process must be defined in order to drive out the requirements of a new document.  Each variation on a given business process may change the requirements of a document.

Defining a business process includes the following areas and are documented in the XML Business Process Definition for the Global Trading Web:

•	Business Process Definition
o	Scope statement
o	Business Examples
o	Use case(s)
•	Primary flow
•	Alternative flow(s)
o	Requirements Covered

The use case explains what takes place within a business process and how the document would be used to support the given business process.  A use case defines the actors involved in the business process, the roles that they play, pre-requisites and post-conditions.  Each of the requirements in the use case is mapped to a primary or alternative flow.  A use case is realized with a real life business example that details out how the use case is truly reflected in the business world.

Thoroughly defining a use case exposes the details of the business process and helps to model the business requirements of the document.  In addition to the Business Process Definition, it will be useful for the requestor to document the Business Transactions and the Choreography. A template for the Business Process Definition can be found in the Appendix

5.1.1.	Business Transactions

The Business Transaction defines how this document will be used as a subset of an overall choreography.  Thinking of how the documents are going to be used in a business transaction will drive out additional requirements.  For example, in the OrderCreateAndSingleOrderResponse Transaction, it is useful for the developer of the new document to know that there can be a response.  However they must think of the other use cases:
•	Can there be no response?
•	Can there be more than one response?
•	Is a response required?
•	What types of activities take place before this transaction?
•	What types of activities take place after this transaction?
•	What roles are involved in this transaction?
•	Why would you perform this transaction?
•	Are there any pre-conditions for this transaction to occur?
•	Does the document require a response to fulfill the business process?
•	Can more than one response be sent to the requesting document?
•	Is the document used in a synchronous or asynchronous manner?

5.1.2.	OrderCreateAndSingleOrderResponse example

Name	OrderCreateAndSingleOrderResponse	
Form ID	BT-1.2-OrderCreateAndSingleOrderResponse	
Transaction Family	Order Placement	
Purpose	This transaction specifies how a buyer may procure goods or services from a supplier.  In this transaction the supplier responds with a single OrderResponse document.  The supplier’s OrderResponse must be a complete acknowledgment to the buyer’s Order.  Partial acknowledgements to the Order are not valid in this business transaction.  

The OrderResponse allows the supplier to communicate the following information to the buyer:
•	Acknowledgment of receipt and valid processing of the Order
•	Acceptance of the Order
•	Rejection of the Order
•	Supplier initiated changes to the Order (most often changes in quantity, price, delivery dates, or schedule)	
Preconditions	1.	Buyer must be able to order from supplier.

2.	Time tolerances must be defined.  The buyer and supplier must agree upon acceptable time-out parameters for the RespondPlaceOrder activity.

3.	Valid response codes and the explicit meaning of the codes must be determined between the buyer and the supplier.

4.	The level at which response codes should be communicated must be determined.  This will be dependent on the functionality of each application and whether or not they can support header level and item detail level responses.	
Possible Predecessors
(Transaction Family) 	Price Checking
Availability Checking	
Possible Successors
(Transaction Family)	Change Order
Advanced Shipment Notice
Invoice
Receipt
Order Status	
Requesting Role
Service

Activity
Action
xCBL Document

Activity
Action
xCBL Document	Buyer
BuyerOrderManagement

PlaceOrder
Send
Order

RespondPlaceOrder  
Receive
OrderResponse	
Responding Role 
Service

Activity
Action
xCBL Document

Activity
Action
xCBL Document	Supplier
SupplierOrderManagement

PlaceOrder
Receive
Order

RespondPlaceOrder
Send
OrderResponse	
Description of Transaction	1.	The BuyerOrderManagement service executes the PlaceOrder activity and sends out the xCBL Order document.

2.	The SupplierOrderManagement service receives the xCBL Order document and executes the PlaceOrder activity.  

3.	The SupplierOrderManagement service executes the RespondPlaceOrder activity and sends out the xCBL OrderResponse document.

4.	The BuyerOrderManagement service receives the xCBL OrderResponse document and executes the RespondPlaceOrder activity.  	
Type Of Transaction	This transaction is asynchronous.	

This information does not need to be document at the time of document creation; however, much of this information needs to be thought about when creating a new document. 

5.1.3.	Choreography

The OrderCreateAndSingleOrderResponse transaction fits into a larger choreography or collaboration.  The XML Business Process Definition for the Global Trading Web describes how a smaller choreography of documents, such as an Order with an Order Response.  However, when creating a new document, one must think of how it fits into the larger business process or processes supported by xCBL documents.  This example details out the overall choreography of xCBL documents for Order Management.  This example does not include Logistics or other potential choreographies to support the overall business process.  For example, when creating an Order document, there is information that is vital to the payment business process.  If the document creator does not define these requirements, then the information would not be captured in the Order document and the overall business process including payment of the Order would not be supported.  A business collaboration brings together business transactions to form the required transactions to support an overall business process.   In a larger scale one can review how many different functional business areas are brought together via collaborations to execute the entire end to end business process.  

•	Order -> ASN -> Invoice -> Payment

This is just one common and simple example of the procure to pay process.  However, this could be extended to include the contract and catalog management on the front end and the invoice reconciliation on the back end of the above described process.  By detailing out the transactions and how they link together to form collaborations, the document creator may discover additional requirements that were not originally present.

Figure 1Procure to Pay Choreography example

5.2.	Requestor responsibility to execute this step
Define the Use Cases for the New Document
Define the Business Transactions for the New Document
Define how the Document will fit into a larger choreography	
5.3.	Deliverable(s) associated with this step
Business Process Specification
•	Use Cases
Business Transactions Document
Choreography
5.4.	Commerce One action for this step

Commerce One will review the deliverables from the requestor and provide any feedback as necessary.  Use cases will be reviewed to determine if they are fully developed.  The business transactions will be reviewed to determine if they are fully developed.  Additionally Commerce One will review the choreography to determine how the new document would fit into larger choreographies
5.5.	Criteria for the next step

The Business Process analysis must be complete in order to begin researching the external requirements.  For publicly available documents, Commerce One must agree with the Business Process analysis and the developed Use Cases.  In some cases, the business process analysis may need review by members of the Global Trading Web to ensure that the analysis is complete.

6.	Research External Requirements

6.1.	Description/purpose of the step

The creation of a new xCBL document may or may not have similar requirements of an existing EDI or XML message.  A trading partner may be migrating from EDI based commerce to an XML based commerce using xCBL as the document payload.  Identification of existing EDI or XML documents will facilitate the creation of the new xCBL document in the following manner:

•	Identifies required data sets and elements for documents
•	Facilitates mapping exercises that may need to take place
•	Identifies the interoperability requirements for translation of documents

Creates an easy way for existing EDI and XML document users to identify xCBL relevance to existing standards
6.2.	Requestor responsibility to execute this step	

Business Documents to review:

•	Related xCBL Documents - xCBL.org (http://www.xcbl.org)
•	Related X12 Documents
•	Related EDIFACT Documents - UN/EDIFACT (http://www.unece.org/trade/untdid/welcome.htm)
•	EbXML Catalog of Common Business Processes - ebXML Catalog of Common Processes – (http://www.ebxml.org/specs/bpPROC.pdf)
•	Related RosettaNet Documents - RosettaNet (http://www.rosettanet.org/)
•	Related OBI Documents – OBI (http://www.openbuy.org/)
•	Related Documents from Other Standards (Industry or Vertical standards)

When reviewing the existing documents, it will be useful to record any data elements that could be used in the new xCBL document.  The process for determining data elements and sets of data is covered in the next section.

At the end of this step, the requestor of the document will contact Commerce One Document Engineering to review the progress and deliverables to date.  This checkpoint is very important prior to beginning the determination of data sets needed to support the new document.  

Reviewing the existing business documents enables the document requestor to gather requirements from accepted industry standards.  Incorporating the best of breed accepted business documents ensures that the newly created xCBL document will gain widespread acceptance across various business communities.
6.3.	Deliverable(s) associated with this step

Documented EDI and XML messages that meet the requirements of the business process associated with the new xCBL document.
6.4.	Commerce One action for this step

Document Engineering will review the deliverables for completeness and accuracy and determine if any changes are needed prior to identification of data elements and document creation.
6.5.	Criteria for the next step

Relevant EDI and XML messages have been identified

7.	Identify Data for New Document

7.1.	Description/purpose of the step

Identification of data elements is the last major step to compose the payload of the xCBL document.  After going through the due diligence of documenting the process and identifying relevant standards, it is time to actually build the document.  When building a new document, the user should refer to the xCBL Style Guide for the process of naming new elements, using existing components, the general structure and style of the new document..  xCBL has a rich catalog of core components that can be re-used in new documents.  The intent is for the user to not re-invent the wheel, but instead to make use of the best practice core components already embedded into xCBL.  

An xCBL document is not intended to solely support the needs of one application interfacing with a different application, instead, it is intended to be an open standards based document that is not constrained by any particular application, service or vendor.  The identification of the data elements and subsets of data is where the document creator must identify industry or horizontal requirements of data.  The user can refer to the identified existing external business documents as a basis for creation of the xCBL document.  There is a danger with simply converting an existing EDI message into xCBL, because that EDI message may contain information that is no longer relevant or is just not used and therefore should not be perpetuated in xCBL, for example, EDI routing information.  This is an intensive process to review all of the relevant existing documents and current application / service requirements to determine what data will be included in the new xCBL document.  There are some objective ways to determine the data including:
•	Review current application requirements
•	Review implementation guides for EDI from various sources

There are also subjective ways to determine the data including:
•	Experience with EDI implementations
•	Request review from user community

There are some data elements that are needed for a given vertical community that may or may not be needed for other vertical industries or the overall horizontal community.  This information will be flagged for review to see if this information should be included in a Community Profile, a profile that contains data specific to a given trading community or vertical industry.  The important step here is to guarantee that the document will be generic enough to support the needs of large trading community and not just an implementation between two specific trading partners.  Identification of all potential elements is essential at this step.  
7.2.	Requestor responsibility to execute this step

Once the user has identified the data elements they feel are needed for the new document, they can begin to simply list out the data elements needed in the new xCBL document.  For each data element, the user will identify the type of element (string, integer, etc..) and if there is an enumerated list of values associated with the element.  The next step in the process is to review the data elements with document engineering and put out for review to the GTW and user communities.  This step will ensure that additional data elements are considered for inclusion in the new document.

The user can begin to structure their new document using the XML Generation Tool” available for download from http://www.xcbl.org.  This document creation tool allows the user to begin to construct the document and enter in definitions for the elements.  Additionally, this tool can pull information from existing core components and populate the structure with the elements and definitions.	
7.3.	Deliverable(s) associated with this step

Data elements from the various EDI and XML messages are documented and definitions have been captured.
7.4.	Commerce One action for this step
Review the data sets provided by the requestor.  Document Engineering will compare to existing standards and determine if any data elements should not be included as well as determine if any additional elements should be included.
7.5.	Criteria for the next step

Data Elements have been entered into the BP Spec tool and the output is provided to Commerce One

8.	Review and Revise

8.1.	Description/purpose of the step

The review and revise allows for public comment on the new xCBL document.  This is essential to ensure that it incorporates the requirements from various interested parties.  (Public review will not take place on proprietary documents.)
8.2.	Requestor responsibility to execute this step	

The requestor of the document submits all of the requirements and the data needed for the new xCBL document to Commerce One document engineering.    The submitter and Document Engineering will determine a resolution for any issues or concerns and incorporate into a public draft of the document.

The public draft of the new document will be announced to the GTW and any other interested parties.  There will be a timeframe for comments on the public draft, typically thirty days.  Document Engineering and the submitter will review all comments and respond where needed to questions or issues raised by reviewers.  The Submitter and Document Engineering will come together after the public review to make and changes where needed to support the needs of the greater public community.  

8.3.	Deliverable(s) associated with this step

Once the final review has been made, the submitter will formalize their request to Document Engineering for a new document to be introduced into the xCBL library.  Document Engineering will build a beta version of the xCBL document and associated documentation 
8.4.	Commerce One action for this step

Document engineering reviews the provided documentation and data requirements for completeness and accuracy.  Document engineering will ensure that the document will meet the largest possible user community by ensuring openness and standards based document creation.  Document engineering will review any issues or concerns with the submitter of the document.

Document Engineering will compile a beta  version  of xCBL message with a version of the library.
8.5.	Criteria for the next step

A beta version of the document is built available to interested trading partners, and vendors to begin to build applications or services towards.  The Beta process may drive out additional requirements or change requests against the document.  These change requests will flow through the traditional Commerce One change control process.  Once the beta program is over, Document Engineering will create a final build of the new document.

9.	Finalize and Build
9.1.	Description/purpose of the step

This step reviews all of the feedback from the previous step and incorporates any changes into the document.  This step also determines when the document will become publicly available if the document is of general use.
9.2.	Requestor responsibility to execute this step	

The requestor has no responsibilities at this step except any informal communication with Commerce One
9.3.	Deliverable(s) associated with this step

A finalized xCBL document is created and a delivery date identified for the new document. Note that the final release of the new document may be dependent on release date for a new version of the xCBL library.
9.4.	Commerce One action for this step

After the review and revision to the document, it is ready to be built and to be included in the xCBL library.  Commerce One Product Management and engineering will determine if the new document is to be included in the next formal release of xCBL, or if it can be released to the public in an independent release.  There are a number of issues that may need to be worked out if the document is release as an independent document.  These issues include; document transformations, application support, interoperability requirements, etc.  

Prior to the finalized build, it will be determined if the new document will become a publicly available xCBL document or if it will be included in a private namespace by the users of the document.
9.5.	Criteria for the next step

Document is added to the xCBL library for public use.

10.	Appendix

10.1.1.	Document Determination Process

10.1.2.	Business Process Definition
Please see the XML Business Process Definition for the Global Trading Web provided by Commerce One. (Insert Link or the actual template-see Valerie for the Template)
10.1.3.	Related Standards

Fill in the chart with the name of the new document and the associated name of the business document from the various standards. 

Document Name	xCBL	X12	EDIFACT	EbXML	RosettaNet	OBI	Other	

								

10.1.4.	Registration Form -Intent To Develop a XML Business Process or Document
Use this registration form to inform Document Engineering that you or your team intends to develop or change a XML Business Process or XML Document (note that XML Document usually exist within an XML Business Process).  Document Engineering will then be able to schedule resources to help your team with the XML Business Process Methodology and the development of the XML Business Process Specification.  Also note that for XML Documents that will be delivered as part of Commerce One products or solutions, Document Engineering is solely responsible for the coding of the document schemas.

Further information on the Commerce One XML Business Process Methodology can be found on Insite at http://insite.commerceone.com/engineering/doceng/xbpm.html.

Registration Instructions:
1.	Complete form on following page(s). The form requires you to do some preliminary research for the XML Business Process and Document Development Information section.
2.	Delete this cover page from document
3.	Email form to XMLRegistration (xCBLSupport@commerceone.com)

If you have any questions or need help completing this form, send email to XMLRegistration  (xCBLSupport@commerceone.com).

Resources for section XML Business Process and Document Development Information:
•	RosettaNet (http://www.rosettanet.org/)
•	UN/EDIFACT (http://www.unece.org/trade/untdid/welcome.htm)- UN Trade Data Interchange Directory (EDIFACT schemas)
•	X12 - at CommerceDesk (http://www.commercedesk.com/content/home/default.asp)
•	Customers (possible resource for EDI Message Implementation Guides)

Basic Registration Information	
Process Title		
Purpose		
Company		
Project		
Visibility	[Private | Portal | GTW]	
Public/Confidential	[Public | Confidential] (Confidential process development will not be announced to the GTW)	
Intent	[New Business Process | Change Business Process | New Document | Change Document | Registration of Previously Developed Process]	

Registrant Information	
Name		
Phone Number		
Email Address		

XML Business Process and Document Development Information	
Target Start Date		
Target Completion Date		
Target Portal		
Target Vertical		
Name of the requesting application / service		
Name of the responding application / service		
Name of potential requesting application(s) / service(s)		
Name of the potential responding application(s) / service(s)		
Suggested Co-participants/ co-developers	(Identify any other companies that you think would be interested in participating in the development of the business process. "None," "Unknown," and "TBD" are acceptable entries.)	
Customer/Industry Contacts	(List customer and industry contacts that will participate as domain experts and reviewers.  There must be at least one contact.)	
Documents To Be Developed	(Identify any known documents that will need to be developed.  For example, "Purchase Order - X12 850 equivalent."  "Unknown" and "TBD" are acceptable entries.)	
Known Related/Similar Business Processes	
Related xCBL Processes	[None | Unknown | <process name>]	
Related X12 Processes	[None | Unknown | <process/MIG name>]	
Related EDIFACT Processes	[None | Unknown | <process/MIG name>]	
Related RosettaNet Processes	[None | Unknown | <process name>]	
Related OBI Processes	[None | Unknown | <process name>]	
Related Processes from Other Standards	[None | Unknown | <process/MIG name> + <standard name>]	
Known Related/Similar Business Documents	
Related xCBL Documents	[None | Unknown | <document name>]	
Related X12 Documents	[None | Unknown | <document name>]	
Related EDIFACT Documents	[None | Unknown | <document name>]	
Related RosettaNet Documents	[None | Unknown | <document name>]	
Related OBI Documents	[None | Unknown | <document name>]	
Related Documents from Other Standards	[None | Unknown | <document name> + <standard name>]	

Notes	

Document Engineering Use Only	
xCBL Release Version	
2.0		
2.2		
3.0		
Other		
Comments