ࡱ> .? ~  \ ] ^ |J|{{{{{D` Bbjbj R8jjj4$i i i hvi q R ^ R9 (4 4 4 G :    $ h j, C G , , 4 4  . . . , 4 j4 . , . . ; jO 4 `*i ,  N L@" 0R ]  B- N k 6 j } a! ~. $ ' c} } } . d} } } R , , , , 6RdRb|  The Workflow Management Coalition Specification Workflow Management Coalition Workflow Standard Process Definition Interface -- XML Process Definition Language Document Number WFMC-TC-1025 Document Status Final September 7, 2005 Version 1.13 Copyright ( 2005 The Workflow Management Coalition All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of the Workflow Management Coalition except that reproduction, storage or transmission without permission is permitted if all copies of the publication (or portions thereof) produced thereby contain a notice that the Workflow Management Coalition and its members are the owners of the copyright therein. Workflow Management Coalition 2436 N. Federal Highway #374 Lighthouse Point, Fl 33064 USA Tel: +1 954 782 3376 Fax: +1 954 782 6365 Email: wfmc@wfmc.org WWW: http://www.wfmc.org The WfMC logo and Workflow Management Coalition name are service marks of the Workflow Management Coalition. Neither the Workflow Management Coalition nor any of its members make any warranty of any kind whatsoever, express or implied, with respect to the Specification, including as to non-infringement, merchantability or fitness for a particular purpose. This Specification is provided as is. Table of Content  TOC \o "1-4" \h \z  HYPERLINK \l "_Toc113870910" 1. Change History  PAGEREF _Toc113870910 \h 4  HYPERLINK \l "_Toc113870911" 1.1. Acknowledgements  PAGEREF _Toc113870911 \h 6  HYPERLINK \l "_Toc113870912" 2. Audience  PAGEREF _Toc113870912 \h 6  HYPERLINK \l "_Toc113870913" 3. Purpose  PAGEREF _Toc113870913 \h 6  HYPERLINK \l "_Toc113870914" 4. Introduction  PAGEREF _Toc113870914 \h 6  HYPERLINK \l "_Toc113870915" 4.1. Conformance  PAGEREF _Toc113870915 \h 7  HYPERLINK \l "_Toc113870916" 4.2. XPDL Version 1.0 Compatibility  PAGEREF _Toc113870916 \h 7  HYPERLINK \l "_Toc113870917" 4.3. References  PAGEREF _Toc113870917 \h 8  HYPERLINK \l "_Toc113870918" 5. Overview of Process Definition Interchange  PAGEREF _Toc113870918 \h 8  HYPERLINK \l "_Toc113870919" 5.1. Approaches to Process Definition Interchange  PAGEREF _Toc113870919 \h 9  HYPERLINK \l "_Toc113870920" 6. Meta-Model  PAGEREF _Toc113870920 \h 10  HYPERLINK \l "_Toc113870921" 6.1. Processes and Packages  PAGEREF _Toc113870921 \h 10  HYPERLINK \l "_Toc113870922" 6.2. Package Meta-Model  PAGEREF _Toc113870922 \h 11  HYPERLINK \l "_Toc113870923" 6.2.1. Process Repository  PAGEREF _Toc113870923 \h 12  HYPERLINK \l "_Toc113870924" 6.2.1.1. Redefinition and Scope  PAGEREF _Toc113870924 \h 12  HYPERLINK \l "_Toc113870925" 6.3. Process Meta-Model  PAGEREF _Toc113870925 \h 13  HYPERLINK \l "_Toc113870926" 6.4. Entities Overview  PAGEREF _Toc113870926 \h 14  HYPERLINK \l "_Toc113870927" 6.4.1. Swimlanes  PAGEREF _Toc113870927 \h 14  HYPERLINK \l "_Toc113870928" 6.4.1.1. Pool  PAGEREF _Toc113870928 \h 14  HYPERLINK \l "_Toc113870929" 6.4.1.2. Lane  PAGEREF _Toc113870929 \h 14  HYPERLINK \l "_Toc113870930" 6.4.2. Process Definition  PAGEREF _Toc113870930 \h 14  HYPERLINK \l "_Toc113870931" 6.4.3. Process Activity  PAGEREF _Toc113870931 \h 14  HYPERLINK \l "_Toc113870932" 6.4.4. Transition Information  PAGEREF _Toc113870932 \h 15  HYPERLINK \l "_Toc113870933" 6.4.5. Participant Declaration  PAGEREF _Toc113870933 \h 15  HYPERLINK \l "_Toc113870934" 6.4.6. Application Declaration  PAGEREF _Toc113870934 \h 15  HYPERLINK \l "_Toc113870935" 6.4.7. Artifact  PAGEREF _Toc113870935 \h 15  HYPERLINK \l "_Toc113870936" 6.4.8. Message Flow  PAGEREF _Toc113870936 \h 16  HYPERLINK \l "_Toc113870937" 6.4.9. Association  PAGEREF _Toc113870937 \h 16  HYPERLINK \l "_Toc113870938" 6.4.10. Relevant data field  PAGEREF _Toc113870938 \h 16  HYPERLINK \l "_Toc113870939" 6.4.11. Data Types and Expressions  PAGEREF _Toc113870939 \h 16  HYPERLINK \l "_Toc113870940" 6.4.12. System and Environmental Data  PAGEREF _Toc113870940 \h 16  HYPERLINK \l "_Toc113870941" 6.4.13. Resource Repository  PAGEREF _Toc113870941 \h 16  HYPERLINK \l "_Toc113870942" 6.4.14. Vendor or User specific Extensions  PAGEREF _Toc113870942 \h 16  HYPERLINK \l "_Toc113870943" 6.4.14.1. Extended Elements and Attributes  PAGEREF _Toc113870943 \h 16  HYPERLINK \l "_Toc113870944" 6.4.14.2. Extended parameter mapping  PAGEREF _Toc113870944 \h 17  HYPERLINK \l "_Toc113870945" 7. XML Process Definition Language  PAGEREF _Toc113870945 \h 18  HYPERLINK \l "_Toc113870946" 7.1. Elements Common for Multiple Entities  PAGEREF _Toc113870946 \h 18  HYPERLINK \l "_Toc113870947" 7.1.1. Graphic Information  PAGEREF _Toc113870947 \h 18  HYPERLINK \l "_Toc113870948" 7.1.1.1. NodeGraphicsInfo  PAGEREF _Toc113870948 \h 18  HYPERLINK \l "_Toc113870949" 7.1.1.2. ConnectorGraphicsInfo  PAGEREF _Toc113870949 \h 19  HYPERLINK \l "_Toc113870950" 7.1.2. Extended Attributes  PAGEREF _Toc113870950 \h 20  HYPERLINK \l "_Toc113870951" 7.1.2.1. Anonymous Extended Attribute  PAGEREF _Toc113870951 \h 20  HYPERLINK \l "_Toc113870952" 7.1.2.2. Namespace Qualified Extensions  PAGEREF _Toc113870952 \h 21  HYPERLINK \l "_Toc113870953" 7.1.3. Formal Parameters  PAGEREF _Toc113870953 \h 21  HYPERLINK \l "_Toc113870954" 7.1.3.1. Parameter passing semantics  PAGEREF _Toc113870954 \h 22  HYPERLINK \l "_Toc113870955" 7.1.3.2. Concurrency semantics  PAGEREF _Toc113870955 \h 22  HYPERLINK \l "_Toc113870956" 7.1.3.3. Formal-actual parameter mapping  PAGEREF _Toc113870956 \h 23  HYPERLINK \l "_Toc113870957" 7.1.4. External Reference  PAGEREF _Toc113870957 \h 23  HYPERLINK \l "_Toc113870958" 7.1.4.1. Web Services  PAGEREF _Toc113870958 \h 23  HYPERLINK \l "_Toc113870959" 7.1.5. Assignment  PAGEREF _Toc113870959 \h 24  HYPERLINK \l "_Toc113870960" 7.1.6. Category  PAGEREF _Toc113870960 \h 25  HYPERLINK \l "_Toc113870961" 7.1.7. Artifact  PAGEREF _Toc113870961 \h 25  HYPERLINK \l "_Toc113870962" 7.1.7.1. Object  PAGEREF _Toc113870962 \h 26  HYPERLINK \l "_Toc113870963" 7.1.7.2. DataObject  PAGEREF _Toc113870963 \h 27  HYPERLINK \l "_Toc113870964" 7.2. Package Definition  PAGEREF _Toc113870964 \h 27  HYPERLINK \l "_Toc113870965" 7.2.1. Package definition Header  PAGEREF _Toc113870965 \h 29  HYPERLINK \l "_Toc113870966" 7.2.1.1. Vendor extensions  PAGEREF _Toc113870966 \h 30  HYPERLINK \l "_Toc113870967" 7.2.2. Redefinable Header  PAGEREF _Toc113870967 \h 31  HYPERLINK \l "_Toc113870968" 7.2.3. Conformance Class Declaration  PAGEREF _Toc113870968 \h 33  HYPERLINK \l "_Toc113870969" 7.2.4. Script  PAGEREF _Toc113870969 \h 33  HYPERLINK \l "_Toc113870970" 7.2.5. External Package  PAGEREF _Toc113870970 \h 34  HYPERLINK \l "_Toc113870971" 7.3. Application Declaration  PAGEREF _Toc113870971 \h 35  HYPERLINK \l "_Toc113870972" 7.3.1. Invocation Parameters  PAGEREF _Toc113870972 \h 36  HYPERLINK \l "_Toc113870973" 7.3.2. Application Types  PAGEREF _Toc113870973 \h 36  HYPERLINK \l "_Toc113870974" 7.3.2.1. EJB  PAGEREF _Toc113870974 \h 36  HYPERLINK \l "_Toc113870975" 7.3.2.2. Pojo  PAGEREF _Toc113870975 \h 37  HYPERLINK \l "_Toc113870976" 7.3.2.3. XSLT  PAGEREF _Toc113870976 \h 37  HYPERLINK \l "_Toc113870977" 7.3.2.4. Script  PAGEREF _Toc113870977 \h 38  HYPERLINK \l "_Toc113870978" 7.3.2.5. WebService  PAGEREF _Toc113870978 \h 38  HYPERLINK \l "_Toc113870979" 7.3.2.6. BusinessRule  PAGEREF _Toc113870979 \h 39  HYPERLINK \l "_Toc113870980" 7.3.2.7. Form  PAGEREF _Toc113870980 \h 39  HYPERLINK \l "_Toc113870981" 7.4. Swimlanes  PAGEREF _Toc113870981 \h 40  HYPERLINK \l "_Toc113870982" 7.4.1. Pool  PAGEREF _Toc113870982 \h 40  HYPERLINK \l "_Toc113870983" 7.4.2. Lane  PAGEREF _Toc113870983 \h 41  HYPERLINK \l "_Toc113870984" 7.5. Process Definition  PAGEREF _Toc113870984 \h 42  HYPERLINK \l "_Toc113870985" 7.5.1. Process Definition Header  PAGEREF _Toc113870985 \h 45  HYPERLINK \l "_Toc113870986" 7.5.2. Process Redefinable Header  PAGEREF _Toc113870986 \h 48  HYPERLINK \l "_Toc113870987" 7.5.3. Activity Set/Embedded SubProcess  PAGEREF _Toc113870987 \h 49  HYPERLINK \l "_Toc113870988" 7.5.4. ProcessType in BPMN mapping to WS-BPEL  PAGEREF _Toc113870988 \h 50  HYPERLINK \l "_Toc113870989" 7.5.5. Status  PAGEREF _Toc113870989 \h 50  HYPERLINK \l "_Toc113870990" 7.5.6. SuppressJoinFailure  PAGEREF _Toc113870990 \h 51  HYPERLINK \l "_Toc113870991" 7.5.7. EnableInstanceCompensation  PAGEREF _Toc113870991 \h 51  HYPERLINK \l "_Toc113870992" 7.5.8. AdHoc  PAGEREF _Toc113870992 \h 51  HYPERLINK \l "_Toc113870993" 7.6. Process Activity  PAGEREF _Toc113870993 \h 51  HYPERLINK \l "_Toc113870994" 7.6.1. Execution Control Attributes  PAGEREF _Toc113870994 \h 56  HYPERLINK \l "_Toc113870995" 7.6.2. Route Activity  PAGEREF _Toc113870995 \h 56  HYPERLINK \l "_Toc113870996" 7.6.2.1. Gateway Activity  PAGEREF _Toc113870996 \h 57  HYPERLINK \l "_Toc113870997" 7.6.2.2. Examples of Gateways and their Representation  PAGEREF _Toc113870997 \h 58  HYPERLINK \l "_Toc113870998" 7.6.3. Block Activity  PAGEREF _Toc113870998 \h 59  HYPERLINK \l "_Toc113870999" 7.6.4. Event Activity  PAGEREF _Toc113870999 \h 59  HYPERLINK \l "_Toc113871000" 7.6.4.1. Start Event  PAGEREF _Toc113871000 \h 60  HYPERLINK \l "_Toc113871001" 7.6.4.2. Intermediate Event  PAGEREF _Toc113871001 \h 61  HYPERLINK \l "_Toc113871002" 7.6.4.3. End Event  PAGEREF _Toc113871002 \h 63  HYPERLINK \l "_Toc113871003" 7.6.4.4. Common Elements Used in Start, Intermediate and End Events  PAGEREF _Toc113871003 \h 64  HYPERLINK \l "_Toc113871004" 7.6.4.5. Examples of Events and their representation  PAGEREF _Toc113871004 \h 68  HYPERLINK \l "_Toc113871005" 7.6.5. Implementation Alternatives  PAGEREF _Toc113871005 \h 69  HYPERLINK \l "_Toc113871006" 7.6.5.1. No Implementation  PAGEREF _Toc113871006 \h 69  HYPERLINK \l "_Toc113871007" 7.6.5.2. Tool  PAGEREF _Toc113871007 \h 70  HYPERLINK \l "_Toc113871008" 7.6.5.3. Task  PAGEREF _Toc113871008 \h 70  HYPERLINK \l "_Toc113871009" 7.6.5.4. Subflow/ProcessRef  PAGEREF _Toc113871009 \h 74  HYPERLINK \l "_Toc113871010" 7.6.5.5. Reference  PAGEREF _Toc113871010 \h 76  HYPERLINK \l "_Toc113871011" 7.6.6. Performer Relationship  PAGEREF _Toc113871011 \h 77  HYPERLINK \l "_Toc113871012" 7.6.7. Deadline  PAGEREF _Toc113871012 \h 77  HYPERLINK \l "_Toc113871013" 7.6.8. Simulation Information  PAGEREF _Toc113871013 \h 79  HYPERLINK \l "_Toc113871014" 7.6.9. Transition Restriction  PAGEREF _Toc113871014 \h 80  HYPERLINK \l "_Toc113871015" 7.6.9.1. Join  PAGEREF _Toc113871015 \h 81  HYPERLINK \l "_Toc113871016" 7.6.9.2. Split  PAGEREF _Toc113871016 \h 82  HYPERLINK \l "_Toc113871017" 7.6.10. Conformance Classes  PAGEREF _Toc113871017 \h 84  HYPERLINK \l "_Toc113871018" 7.6.11. InputSets  PAGEREF _Toc113871018 \h 84  HYPERLINK \l "_Toc113871019" 7.6.12. OutputSets  PAGEREF _Toc113871019 \h 85  HYPERLINK \l "_Toc113871020" 7.6.13. Transaction  PAGEREF _Toc113871020 \h 86  HYPERLINK \l "_Toc113871021" 7.6.14. Loop  PAGEREF _Toc113871021 \h 87  HYPERLINK \l "_Toc113871022" 7.7. Transition Information  PAGEREF _Toc113871022 \h 89  HYPERLINK \l "_Toc113871023" 7.7.1. Condition  PAGEREF _Toc113871023 \h 90  HYPERLINK \l "_Toc113871024" 7.7.1.1. Exception Conditions  PAGEREF _Toc113871024 \h 91  HYPERLINK \l "_Toc113871025" 7.8. Partner Links  PAGEREF _Toc113871025 \h 92  HYPERLINK \l "_Toc113871026" 7.8.1. Partner Link Type  PAGEREF _Toc113871026 \h 92  HYPERLINK \l "_Toc113871027" 7.8.2. Partner Link  PAGEREF _Toc113871027 \h 93  HYPERLINK \l "_Toc113871028" 7.9. Messaging  PAGEREF _Toc113871028 \h 94  HYPERLINK \l "_Toc113871029" 7.9.1. Message Flow  PAGEREF _Toc113871029 \h 94  HYPERLINK \l "_Toc113871030" 7.9.2. Message Type  PAGEREF _Toc113871030 \h 95  HYPERLINK \l "_Toc113871031" 7.9.3. End Point  PAGEREF _Toc113871031 \h 96  HYPERLINK \l "_Toc113871032" 7.9.4. Web ServiceOperation  PAGEREF _Toc113871032 \h 96  HYPERLINK \l "_Toc113871033" 7.9.5. Web Service Fault Catch  PAGEREF _Toc113871033 \h 97  HYPERLINK \l "_Toc113871034" 7.10. Association  PAGEREF _Toc113871034 \h 98  HYPERLINK \l "_Toc113871035" 7.11. Participants  PAGEREF _Toc113871035 \h 99  HYPERLINK \l "_Toc113871036" 7.11.1. Participant Entity Types  PAGEREF _Toc113871036 \h 100  HYPERLINK \l "_Toc113871037" 7.12. Relevant data field  PAGEREF _Toc113871037 \h 101  HYPERLINK \l "_Toc113871038" 7.13. Data Types  PAGEREF _Toc113871038 \h 102  HYPERLINK \l "_Toc113871039" 7.13.1. Basic Data Types  PAGEREF _Toc113871039 \h 103  HYPERLINK \l "_Toc113871040" 7.13.2. Complex Data Types  PAGEREF _Toc113871040 \h 103  HYPERLINK \l "_Toc113871041" 7.13.2.1. Schema Type  PAGEREF _Toc113871041 \h 104  HYPERLINK \l "_Toc113871042" 7.13.2.2. Record Type  PAGEREF _Toc113871042 \h 104  HYPERLINK \l "_Toc113871043" 7.13.2.3. Union Type  PAGEREF _Toc113871043 \h 104  HYPERLINK \l "_Toc113871044" 7.13.2.4. Enumeration Type  PAGEREF _Toc113871044 \h 105  HYPERLINK \l "_Toc113871045" 7.13.2.5. Array Type  PAGEREF _Toc113871045 \h 105  HYPERLINK \l "_Toc113871046" 7.13.2.6. List Type  PAGEREF _Toc113871046 \h 106  HYPERLINK \l "_Toc113871047" 7.13.3. Declared Data Types  PAGEREF _Toc113871047 \h 106  HYPERLINK \l "_Toc113871048" 7.13.3.1. Type Declaration  PAGEREF _Toc113871048 \h 106  HYPERLINK \l "_Toc113871049" 7.13.3.2. Declared Type  PAGEREF _Toc113871049 \h 107  HYPERLINK \l "_Toc113871050" 8. Samples  PAGEREF _Toc113871050 \h 109  HYPERLINK \l "_Toc113871051" 8.1. Sample Process  PAGEREF _Toc113871051 \h 109  HYPERLINK \l "_Toc113871052" 8.1.1. The Processes  PAGEREF _Toc113871052 \h 109  HYPERLINK \l "_Toc113871053" 8.1.1.1. The EOrder Main Process  PAGEREF _Toc113871053 \h 109  HYPERLINK \l "_Toc113871054" 8.1.1.2. The CreditCheck Subprocess  PAGEREF _Toc113871054 \h 110  HYPERLINK \l "_Toc113871055" 8.1.1.3. The FillOrder Subprocess  PAGEREF _Toc113871055 \h 110  HYPERLINK \l "_Toc113871056" 8.1.2. Type Declarations  PAGEREF _Toc113871056 \h 110  HYPERLINK \l "_Toc113871057" 8.1.3. ExtendedAttributes  PAGEREF _Toc113871057 \h 112  HYPERLINK \l "_Toc113871058" 8.1.4. External References  PAGEREF _Toc113871058 \h 113  HYPERLINK \l "_Toc113871059" 8.1.5. Sample XPDL  PAGEREF _Toc113871059 \h 113  HYPERLINK \l "_Toc113871060" 8.2. Extending XPDL Schema  PAGEREF _Toc113871060 \h 128  HYPERLINK \l "_Toc113871061" 8.2.1. Xyz Schema  PAGEREF _Toc113871061 \h 128  HYPERLINK \l "_Toc113871062" 8.2.2. Xyz Test XPDL Document  PAGEREF _Toc113871062 \h 129  HYPERLINK \l "_Toc113871063" 9. XPDL Schema  PAGEREF _Toc113871063 \h 130  HYPERLINK \l "_Toc113871064" 10. Figures and Tables  PAGEREF _Toc113871064 \h 176  HYPERLINK \l "_Toc113871065" 10.1. Figures  PAGEREF _Toc113871065 \h 176  HYPERLINK \l "_Toc113871066" 10.2. Tables  PAGEREF _Toc113871066 \h 176  Change History Version 1.13 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Updated the Specification to include discussion of new properties that determine starting ActivitySet and Activity. Fixed minor errors in schema. (NodeGraphicsInfos, ConnectorGraphicsInfos, starting ActivitySet and Activity properties. Version 1.12 Editor: Mike Marin ( HYPERLINK "mailto:mmarin@filenet.com" mmarin@filenet.com) Worked on the web services area and introduced PartnerLink, PartnerLinkType, EndPoint, and Catch. Implemented a new extensibility model and reverted extensible attributes (anonymous extensions) to the XPDL 1.0 model. Introduced NodeGraphicInfos and ConnectorGraphInfos. Added an example of extending the XPDL schema. Version 1.11 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Added Discussion and attribute tables for the seven application types. (Contributed by TIBCO). Version 1.10 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Added the Application Type and seven elements under Type.. Changed DiagramRef to PackageRef. Both Tool and Subflow now have PackageRef. Both Tool and SubFlow now have a choice of ActualParameters or DataMappings. Tool is now under Task, and it was renamed to TaskApplication. Subflow was deprecated and renamed to ProcessRef in XPDL 2.0 (Note that TriggerResultLink has an attribute called also ProcessRef, so this may introduce some confusion). PoolId and LaneId were removed from Activity and Artifact. LaneId was added to NodeGraphicsInfo. NodeGraphicsInfo now has Extended Attributes. StartMode/FinishMode moved to activity attributes. Metamodels updated to reflect changes (e.g. Tool now under task) Removed initial t from all schema type definitions Added Length, Precision andScale Attributes to BasicType element. Version 1.09 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Minor Typos fixed. toolId attribute replaced by ToolId Target attribute type changed to NMTOKEN All schema inserts updated for new approach to Deprecation using name spaces. Version 1.08 Editor: Mike Marin ( HYPERLINK "mailto:mmarin@filenet.com" mmarin@filenet.com) Enhanced document and schema with new extended attributes model. Schema types are now prefixed with t. Changed ExternalPackage id to Id to be compatible with all other Ids. Normalized Name and Id attributes for all entities that require them. Changed Assignment to have Target and Expression entities. Changed TaskScript to be any arbitrary expression. Introduced a ExpressionType type and used for all expressions Updated all the sections with schema Added a section on XPDL version 1.0 compatibility Version 1.07 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Includes changes based on XPDL 1.0 requests Formal parameter index deprecated. AccessLevel attribute of Process made optional with default PUBLIC. Additional attribute for subflow provides name of datafield in which to store instantiation id. Execution attribute for subflow is optional with default SYNCHR. GraphConformance attribute for Conformance class is optional with default NON_BLOCKED. Transition condition may have at most one child element expression. Tool attribute type deprecated: no longer needed since there are no constructs for declaring Procedures or any information about their formal parameters or parameter passing. Hence all Tools should be Applications. DeadlineCondition deprecated. DeadlineDuration element introduced with type = string. . Example redone using BPMN notation Version 1.06 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Includes all editing changes from Justin Brunt (JBrunt@staffware.com). Version 1.05 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Minor Changes to Schema: ProcessType order of elements to preserve compatibility with XPDL 1.0 Minor typos. Instantiate attribute removed from TaskSend and TaskService. TaskSend Message documentation fixed. Explanation of OTHERWISE clause changed for SPLITS. Corrected documentation on Splits and Joins to reflect BPMN extensions. Added documentation in Route Activity section. Package reference extended to include type declarations. Added attribute to External Package Reference. Added reference to external packages for Participant identifiers. Version 1.04 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Minor Changes to Schema: order of elements and some elements made optional. Examples of Gateways and Events Version 1.03 Editor: Robert Shapiro ( HYPERLINK "mailto:rshapiro@capevisions.com" rshapiro@capevisions.com) Inserted text explanations of BPMN constructs used in meta-models. Updated individual schema sections and tables, adding sections for all elements Version 1.02 Editor: Mike Marin ( HYPERLINK mailto:mmarin@filenet.com mmarin@filenet.com) Reorganized document and added new meta-models Version 1.01 Editors: Mike Marin (mmarin@filenet.com) and Robert Shapiro (rshapiro@capevisions.com) Initial draft of bidirectional mapping to BPMN 1.0 Version 1.0 Editor: Roberta Norin ( HYPERLINK "mailto:robertan@attbi.com" robertan@attbi.com). Acknowledgements XPDL2.0 required many hours of work by individuals who had to find time to contribute while carrying out their normal duties for the companies that employ them. Robert Shapiro (Global 360) and Mike Marin (FileNET) did the bulk of the work. Justin Brunt, Wojciech Zurek, Tim Stephenson (Staffware/TIBCO) , Sasa Bojanic (Prozone)and Gangadhar Gouri (Fujitsu Software) made significant contributions. Keith Swensen (Fujitsu Software) provided invaluable organizational support and encouragement. Audience The intended audience for this document is primarily vendor organizations who seek to implement the XML Process Definition Language (XPDL) of the Workflow Management Coalition (WfMC), or using it as a file format for the Business Process Modeling Notation (BPMN) of the Business Process Management Initiative (BPMI). It may also be of interest to those seeking to assess conformance claims made by vendors for their products. Comments should be addressed to the Workflow Management Coalition. Purpose XPDL version 2.0 is back compatible with XPDL version 1.0, and is intended to be used as a file format for BPMN. The original purpose of XPDL is maintained and enhanced by this second version of the specification. The XPDL and the BPMN specifications address the same modeling problem from different perspectives. XPDL provides an XML file format that can be used to interchange process models between tools. BPMN provides a graphical notation to facilitate human communication between business users and technical users, of complex business processes. There are a number of elements that are present in BPMN version 1.0 that were not present in XPDL version 1.0. Those had been incorporated into this version of XPDL. The WfMC has identified five functional interfaces to a process or workflow service as part of its standardization program. This specification forms part of the documentation relating to Interface one - supporting Process Definition Import and Export. This interface includes a common meta-model for describing the process definition (this specification) and also a companion XML schema for the interchange of process definitions. Introduction A variety of different tools may be used to analyse, model, describe and document a business process. The process definition interface defines a common interchange format, which supports the transfer of process definitions between separate products. The interface also defines a formal separation between the development and run-time environments, enabling a process definition, generated by one modelling tool, to be used as input to a number of different run-time products. A process definition, generated by a build-time tool, is capable of interpretation in different run-time products. Process definitions transferred between these products or stored in a separate repository are accessible via the XPDL common interchange format. To provide a common method to access and describe process definitions, a process definition meta-data model has been established. This meta-data model identifies commonly used entities within a process definition. A variety of attributes describe the characteristics of this limited set of entities. Based on this model, vendor specific tools can transfer models via a common exchange format. One of the key elements of XPDL is its extensibility to handle information used by a variety of different tools. XPDL may never be capable of supporting all additional information requirements in all tools. Based upon a limited number of entities that describe a process definition (the "Minimum Meta Model"), XPDL supports a number of differing approaches. One of the most important elements of XPDL is a generic construct that supports vendor specific attributes for use within the common representation. We recommend that any missing attributes be proposed to the WfMC interface one workgroup for inclusion in future releases. This document describes the meta-model, which is used to define the objects and attributes contained within a process definition. The XPDL grammar is directly related to these objects and attributes. This approach needs two operations to be provided by a vendor: Import a process definition from XPDL. Export a process definition from the vendor's internal representation to XPDL. A vendor can use an XSL style sheet to accomplish these two operations. All keywords and terms used within this specification are based upon the WfMC Glossary, or terminology used by BPMN. For the purpose of this document, the terms process definition, business process model, and workflow model are all considered to represent the same concept, and therefore, they are used interchangeably. Conformance A vendor can not claim conformance to this or any other WfMC specification unless specifically authorised to make that claim by the WfMC. WfMC grants this permission only upon the verification of the particular vendors implementation of the published specification, according to applicable test procedures defined by WfMC. Conformance for process definition import / export is essentially based upon conformance to the XPDL grammar. However, there is a mandatory minimum set of objects, as specified within this document, which must be supported within XPDL. But, given the wide variation of capabilities in modelling tools, it is reasonable to assume that an individual tool might conform to this specification but not be able to swap complete definitions with all other conforming products. A product that claims conformance must generate valid, syntactically correct XPDL, and must be able to read valid XPDL files. A valid, syntactically correct XPDL file, must conform and validate against the XPDL schema. XPDL Version 1.0 Compatibility XPDL version 2.0 is compatible with XPDL version 1.0, with minor exceptions. The XPDL schema version 2.0 has a different namespace, and tools wishing to be compatible with XPDL version 1.0 need to understand both XPDL 1.0 and XPDL 2.0 namespaces. The following XPDL version 1.0 elements have been deprecated in version 2.0: Automatic element. Replaced by StartMode and FinishMode attributes of Activity. BlockId attribute of BlockActivity element. Replaced by ActivitySetId. DeadlineCondition element. Replaced with DeadlineDuration. Index attribute in FormalParameter element. Because, FormalParameters must match the order in the declaration, and so there is no need for Index. Manual element. Replaced by StartMode and FinishMode attributes of Activity. Type attribute of Tool element. Because tools are applications and so this attribute is not necessary. (Tools cannot be procedures - from WPDL - because XPDL does not provide any way of defining the formal parameters for procedures.) Note also that Tool is a type of Task: TaskAplication. Xpression element in Condition element. Replaced by Expression. The order in a WorkflowProcess changed from DataFields, Participants, and Applications to be Participants, Applications, and DataFields. This makes the order in Process and package consistent. References The following documents are associated with this document and should be used as a reference. General background information: WfMC, Terminology & Glossary (WfMC-TC-1011) WfMC, Reference Model (WfMC-TC-1003) WfMC, API specifications, which include process definition manipulation APIs: WfMC, Client Application API Specifications (WAPI) (WfMC-TC-1009) WfMC, Process Definition Interchange Process Model (WfMC-TC-1016-P) BPMI, Business Process Modeling Notation (BPMN), version 1.0 May 3, 2004 Process interoperability, used to support process invocation on a remote workflow service: Workflow Interoperability - Abstract Specifications (WfMC-TC-1012) Interoperability - Internet E-mail MIME Binding (WfMC-TC-1018) Accompanying documents: The Resource Model (Organizational Model: WfMC TC-1016-O) BPMN icons and tables used in this document are copyright by the Business Process Management Initiative [BPMI.org], May 3, 2004. All Rights Reserved by BPMI.org. Overview of Process Definition Interchange An XPDL package corresponds to a Business Process Diagram (BPD) in BPMN, and consists of a set of Process Definitions. The WfMC defines a process as: The representation of a business process in a form that supports automated manipulation, such as modeling, or enactment by a workflow [or business] management system. The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc. (WfMC Glossary - WfMC-TC-1011) The process definition provides an environment for a rich description of a process that can be used for the following, Act as a template for the creation and control of instances of that process during process enactment. For simulation and forecasting. As a basis to monitor and analyse enacted processes. For documentation, visualization, and knowledge management. The process definition may contain references to subflows, separately defined, which make up part of the overall process definition. An initial process definition will contain at least the minimal set of objects and attributes necessary to initiate and support process execution. Some of these objects and attributes will be inherited by each created instance of the process. The WfMC Glossary also contains descriptions of, and common terminology for, the basic concepts embodied within a process definition such as activities, transitions, relevant data and participants, etc. Approaches to Process Definition Interchange This specification uses XML as the mechanism for process definition interchange. XPDL forms a common interchange standard that enables products to continue to support arbitrary internal representations of process definitions with an import/export function to map to/from the standard at the product boundary. A variety of different mechanisms may be used to transfer process definition data between systems according to the characteristics of the various business scenarios. In all cases the process definition must be expressed in a consistent form, which is derived from the common set of objects, relationships and attributes expressing its underlying concepts. The principles of process definition interchange are illustrated in  REF _Ref10951734 \h Figure 51: The Concept of the Process Definition Interchange.  EMBED Visio.Drawing.6  Figure  STYLEREF 1 \s 5 SEQ Figure \* ARABIC \s 1 1: The Concept of the Process Definition Interchange Meta-Model The Meta-Model describes the top-level entities contained within a Process Definition, their relationships and attributes (including some which may be defined for simulation or monitoring purposes rather than for enactment). It also defines various conventions for grouping process definitions into related process models and the use of common definition data across a number of different process definitions or models. Processes and Packages The process model includes various entities whose scope may be wider than a single process definition. In particular the definitions of participants, applications and relevant data may be referenced from a number of process definitions. The meta-model assumes the use of a common process definition repository to hold the various entity types comprising the process definition. Within the repository itself and to support the efficient transfer of process definition data to/from the repository, the concept of a package is introduced, which acts as a container for the grouping of common data entities from a number of different process definitions, to avoid redefinition within each individual process definition. The package provides a container to hold a number of common attributes from the process definition entity (author, version, status, etc.). Each process definition contained within the package will automatically inherit any common attributes from the package, unless they are separately re-specified locally within the process definition An XPDL Package corresponds to a BPMN Business Process Diagram. At the level below Package, there are four new elements which are discussed in the sequel: Pools (and their lanes) are associated with processes and are used in layout and to define participants for the sequence flow elements contained within. Message flows are used to represent communication between processes, based on Web Services Description Language (WSDL) protocols. Associations and Artifacts are used to document the process definitions. Associations and the Artifacts they connect to provide additional information for the reader of a BPMN Diagram, but do not directly affect the execution of the Process. Within a package, the scope of the definitions of some entities is global and these entities can be referenced from all process definitions (and associated activities and transitions) contained within the package. Those entities are: participant specification application declaration, and relevant data field The package reference allows the use within the package or its contained objects of references to top-level entities in the referenced external package: Process ids for subflow reference participant specifications application declarations type declarations Conventions on name and identifier management across different packages within the same repository address space to achieve any necessary global uniqueness are for user/vendor definition. The assumed convention during process enactment is that name reference searches follow the sequence: Process ids - firstly within the same model (including any references to process definitions for remote execution on a different service), then within any externally referenced model Applications / participants - firstly within the same model, then within any externally referenced model Relevant data naming must be unique within a package; where such data is passed between processes as parameters the convention at this version of specification is that copy semantics will be used. Responsibility rests with process designers / administrators to ensure consistent name / data type usage within process definitions / models to support subflow operations (including any required remote process interoperability). Package Meta-Model Multiple process definitions are bound together in a model definition. The Package acts as a container for grouping together a number of individual process definitions and associated entity data, which is applicable to all the contained process definitions (and hence requires definition only once).  EMBED Visio.Drawing.11  Figure  STYLEREF 1 \s 6 SEQ Figure \* ARABIC \s 1 1 Package Definition Meta Model The meta-model for the Package identifies the entities and attributes for the exchange, or storage, of process models. It defines various rules of inheritance to associate an individual process definition with entity definitions for participant specification, application declaration and relevant data field, which may be defined at the package level rather than at the level of individual process definitions. The Package Definition allows the specification of a number of common process definition attributes, which will then apply to all individual process definitions contained within the package. Such attributes may then be omitted from the individual process definitions. (If they are re-specified at the level of an individual process definition this local attribute value takes precedence over the global value defined at the package level. Process Repository The process definition import/export interface is assumed to operate to/from a definition repository of some form associated with the process or workflow management system. The import/export interface is realized by the transfer of files containing XPDL into or out of such repository. This interface specification allows the import or export of process definition data at the level of individual process definitions and packages. The internal interface between the repository and control functions is specific to individual vendor products and does not form part of this standard. It is assumed that separation is provided (for example by version control) between repository usage as a static repository (for persistent, ongoing storage of process definition data) and any dynamic usage (for managing changes to the process execution of extant process instances). The local storage structure of the process definition repository is not part of the WfMC standard. The use of a package is defined only as an aid to simplify the import/export of reusable data structures. Where a simple process repository structure is used, operating at a single level of process definition, shared information within an imported package may be replicated into each of the individual process definitions at the import interface (and similarly repacked, if required, for process definition export). Redefinition and Scope The possibility of redefining attributes and meta-model entities and referencing external packages introduces the principles of scope and hierarchy into the XPDL (and process repository) structures. Relevant data field Process relevant data field has a scope that is defined by the directly surrounding meta-model entity and is not nested. The visibility of its identifier is also defined by that entity. Attributes Attributes including extended attributes have a scope that is defined by the directly surrounding meta-model entity and are nested, i.e. may be redefined at a lower level. Example: The name attribute is redefined in each entity definition. The visibility of extended attribute identifiers is within the particular entity and all sub-entities unless the identifier is redefined in a sub-entity. (iii) Participants and applications Participants and applications have a scope and visibility equivalent to extended attributes. All referenced relevant data field and extended attributes have to be defined in the scope where they are used, at least in the same package. For a referenced external package entity that needs itself reference to entities and their identifiers defined in its external package clause the mechanism is started with the root in that package. That guarantees that no conflict takes place if the invoking process has an entity with the same id, which the definer of the referenced package cannot be aware of. The described mechanism of external package provides high flexibility for designers and administrators. One can separate organization descriptions (participant entities) and process definitions in separate models, one can add a new release of a process description or add a new process definition sharing the rest of the definition of previously defined and exchanged models without resubmitting the whole context etc. Process Meta-Model The meta-model identifies the basic set of entities and attributes for the exchange of process definitions. For a Process Definition the following entities must be defined, either explicitly at the level of the process definition, or by inheritance directly or via cross reference from a surrounding package.  EMBED Visio.Drawing.11  Figure  STYLEREF 1 \s 6 SEQ Figure \* ARABIC \s 1 2: Process Definition Meta Model These entities contain attributes that support a common description mechanism for processes. They are described in the subsequent document sections. The XPDL Process and WorkflowProcess correspond to the BPMN Process. At the level below Process, there are two new elements: Assignments and Categories; these are discussed in the sequel. Assignments allow Data Fields (Properties) to be assigned values in the course of execution of a Process. Categories are useful in reporting and analysis of running Processes but do not affect the behavior of the processes. Entities Overview The meta-model identifies the basic set of entities used in the exchange of process definitions. The top-level entities are as follows: Swimlanes Swimlanes are used to facilitate the graphical layout of a collection of processes and may designate participant information at the process level and performer information at the activity level. The Swimlane structure is depicted by a collection of non-overlapping rectangles called Pools. Each Pool may be further subdivided into a number of Lanes. Pool A Pool acts as the container for flow objects (activities) and Sequence Flow (transitions) between them. The Sequence Flow may cross the boundaries between Lanes of a Pool, but cannot cross the boundaries of a Pool. The interaction between Pools, e.g., in a B2B context, is shown through Message Flow. Another aspect of Pools is whether or not there is any activity detailed within the Pool. Thus, a given Pool may be shown as a White Box, with all details exposed, or as a Black Box, with all details hidden. No Sequence Flow is associated with a Black Box Pool, but Message Flow can attach to its boundaries. Each page of the diagram is regarded as an invisible background pool. Activities and sequence flow not within an explicit Pool are treated as contained by the background pool. Lane Lanes are used to subdivide a Pool. All the activities within a Lane may inherit one or more properties from the Lane. A typical use of this is to give the Lanes role names and have the Activities inherit these role names as Participant assignment/Performer expressions. Process Definition The Process Definition entity provides contextual information that applies to other entities within the process. It is a container for the process itself and provides information associated with administration (creation date, author, etc.) or to be used during process execution (initiation parameters to be used, execution priority, time limits to be checked, person to be notified, simulation information, etc.). Process Activity A process definition consists of one or more activities, each comprising a logical, self-contained unit of work within the process. An activity represents work, which will be performed by a combination of resource (specified by participant assignment) and/or computer applications (specified by application assignment). Other optional information may be associated with the activity such as information on whether it is to be started / finished automatically by the process or workflow management system or its priority relative to other activities where contention for resource or system services occurs. Usage of specific relevant data field items by the activity may also be specified. The scope of an activity is local to a specific process definition (although see the description of a subflow activity below). In addition to the tools explicitly declared as applications, an activity may be implemented as one of a number of built-in BPMN tasks. Most of these concern B2B messaging. Their attribute details are discussed in the sequel. An activity may be a subflow - in this case it is a container for the execution of a (separately specified) process definition, which may be executed locally within the same service, or (possibly using the process interoperability interface) on a remote service. The process definition identified within the subflow contains its own definition of activities, internal transitions, resource, and application assignments (although these may be inherited from a common source). In- and out-parameters permit the exchange of any necessary relevant data field between calling and called process (and, where necessary, on return). Such definitions are equivalent to BPMN independent subprocesses. An activity may be a block activity that executes an activity set, or map of activities and transitions. Activities and transitions within an activity set share the name space of the containing process. An activity set is equivalent to a BPMN embedded subprocess. An activity may be a route activity, which performs no work processing (and therefore has no associated resource or applications), but simply supports routing decisions among the incoming transitions and/or among the outgoing transitions. BPMN gateways are represented by Route activities. Finally, an activity may represent a BPMN event. An event is something that happens during the course of a business process. These events affect the flow of the process and usually have a cause (trigger) or an impact (result). There are three types of Events, based on when they affect the flow: Start, Intermediate, and End. Their attribute details are discussed in the sequel. Transition Information Activities are related to one another via flow control conditions (transition information). Each individual transition has three elementary properties, the from-activity, the to-activity and the condition under which the transition is made. Transition from one activity to another may be conditional (involving expressions which are evaluated to permit or inhibit the transition) or unconditional. The transitions within a process may result in the sequential or parallel operation of individual activities within the process. The information related to associated split or join conditions is defined within the appropriate activity, split as a form of post activity processing in the from-activity, join as a form of pre-activity processing in the to- activity. This approach allows the control processing associated with process instance thread splitting and synchronization to be managed as part of the associated activity, and retains transitions as simple route assignment functions. The scope of a particular transition is local to the process definition, which contains it and the associated activities. More complex transitions, which cannot be expressed using the simple elementary transition and the split and join functions associated with the from- and to- activities, are formed using route activities, which can be specified as intermediate steps between real activities allowing additional combinations of split and/or join operations. Using the basic transition entity plus route activities, routing structures of arbitrary complexity can be specified. Since several different approaches to transition control exist within the industry, several conformance classes are specified within XPDL. These are described later in the document. Participant Declaration This provides descriptions of resources that can act as the performer of the various activities in the process definition. The particular resources, which can be assigned to perform a specific activity, are specified as an attribute of the activity, participant assignment, which links the activity to the set of resources (within the participant declaration) which may be allocated to it. The participant declaration does not necessarily refer to a human or a single person, but may also identify a set of people of appropriate skill or responsibility, or machine automata resource rather than human. The meta-model includes some simple types of resource that may be defined within the participant declaration. Application Declaration This provides descriptions of the IT applications or interfaces which may be invoked by the service to support, or wholly automate, the processing associated with each activity, and identified within the activity by an application assignment attribute (or attributes). Such applications may be generic industry tools, specific departmental or enterprise services, or localized procedures implemented within the framework of the process or workflow management system. The application definition reflects the interface between the engine and the application or interface, including any parameters to be passed. Artifact To satisfy additional modeling concepts that are not part of the basic set of flow elements (activities, sequence and message flow), BPMN provides the concept of Artifacts that can be linked to the existing Flow Objects through Associations (see below). Thus, Artifacts do not affect the basic Sequence or Message Flow, nor do they affect mappings to execution languages. At this point, BPMN provides three standard Artifacts: A Data Object, a Group, and an Annotation. Additional standard Artifacts may be added to the BPMN specification in later versions. A modeler or modeling tool may extend a BPD and add new types of Artifacts to a Diagram. Any new Artifact must follow the specified Sequence Flow and Message Flow connection rules. Message Flow A Message Flow is used to show the flow of messages between two participants/processes that are prepared to send and receive them. In BPMN, two separate Pools in the Diagram will represent the two participants/processes (e.g., business entities or business roles). All Message Flow must connect two separate Pools. They can connect to the Pool boundary or to Flow Objects within the Pool boundary. They cannot connect two objects within the same Pool. Association An Association is used to associate information and Artifacts with Flow Objects. Text and graphical non-Flow Objects can be associated with the Flow Objects and Flow. An Association is also used to show the activities used to compensate for an activity. An Association does not have a specific mapping to an execution language element. These objects and the Artifacts they connect to provide additional information for the reader of the BPMN Diagram, but do not directly affect the execution of the Process. Relevant data field This defines the data that is created and used within each process instance during process execution. The data is made available to activities or applications executed during the process and may be used to pass persistent information or intermediate results between activities and/or for evaluation in conditional expressions such as in transitions or participant assignment. Relevant data field is of particular type. XPDL includes definition of various basic and complex data types, (including date, string, etc.) Activities, invoked applications and/or transition conditions may refer to process relevant data field. Data Types and Expressions The meta-model (and associated XPDL) assumes a number of standard data types (string, reference, integer, float, date/time, etc.); such data types are relevant to data fields, system or environmental data or participant data. Expressions may be formed using such data types to support conditional evaluations and assignment of new values to data fields. Data types may be extended using an XML schema or a reference to data defined in an external source. System and Environmental Data This is data which is maintained by the process or workflow management system or the local system environment, but which may be accessed by activities or used by the process or workflow management system in the evaluation of conditional expressions and assignments in the same way as relevant data fields. Resource Repository The resource repository accounts for the fact that participants can be humans, programs, or machines. In more sophisticated scenarios the participant declaration may refer to a resource repository, which may be an Organizational Model in the case of human participants. Note that this specification does not define or require a resource repository. Vendor or User specific Extensions Although the meta-model and associated XPDL contain most of the constructs, which are likely to be required in the exchange of process definitions, there may be circumstances under which additional information (user or vendor specific) will need to be included within a process definition. Users and vendors are encouraged to work as far as possible within the standard entity / attribute sets; however, when extensions are needed the XPDL schema provides a standard way to extend it with vendor or user specific extensions. Extended Elements and Attributes The primary method to support such extensions is by the use of extended attributes. Extended attributes are those defined by the user or vendor, where necessary, to express any additional entity characteristics. XPDL schema supports namespace-qualified extensions to all the XPDL elements. The XPDL elements can be extended by adding new child elements, and new attributes. Extended parameter mapping No specific details of the scheme for encoding and passing parameter data are defined within this specification. Where parameters are passed on remote subflow invocation using the workflow Interoperability Specification (interface four), specifications are provided for the mapping of such parameters (for example into wf-XML exchanges) using the operations within the concrete syntax specification for interoperability. Any local scheme for parameter mapping and encoding is vendor defined on a product-by-product basis and lies outside the scope of this specification. XML Process Definition Language Elements Common for Multiple Entities Graphic Information Graphic information is optional and tool dependent. The graphic information (NodeGraphicsInfo and ConnectorGraphicsInfo) may appear multiple times on each XPDL element, depending on the number of tools that have added the graphical information to the XPDL file. Each tool, identificated by ToolId, can add its own graphical information. Therefore, each tool can display and represent the same XPDL in totally different ways, because each tool uses its own graphical information, but retains the graphical information from other tools. NodeGraphicsInfo NodeGraphicsInfo is an optional entity that can be used by a tool to describe graphical information. Each graphical node in XPDL (Activity, Pool, Lane, Artifact) has a list of NodeGraphicsInfo, one for each tool that has saved the corresponding information in the XPDL file. If a tool chooses to use the NodeGraphicsInfo, it should select a tool id, which can be the name of the tool. Therefore multiple tools can work using the same XPDL file and displaying the process with a different presentation layout. DescriptionBorder ColorColor of the border, expressed as a string. Tool specific and depends on ToolId.CoordinatesX and Y coordinates of nodes upper left corner (bounding box). Tool specific and depends on ToolId.Fill ColorColor of the fill, expressed as a string. Tool specific and depends on ToolId.HeightHeight of the node. Tool specific and depends on ToolId.LaneIdIf the node is in a Lane, this is the Id of the Lane.Tool IdTool id. This may correspond to the name of the tool generating the XPDL file. Note that multiple NodeGraphicsInfo elements may appear in an element. This allows each tool to have its NodeGraphicsInfo, allowing for different tools using the same XPDL file to represent the element in totaly different ways. Each tool read and writes its own NodeGraphicsInfo based on its ToolId, and it leave untouch the NodeGraphicsInfo from oter tools.Is VisibleTrue indicates node should be shown.PageThe name of the page on which this node should be displayed.ShapeShape, expressed as a string: used to override BPMN shapes.WidthWidth of the node. ). Tool specific and depends on ToolId.Table  SEQ Table \* ARABIC 1: Node Graphics Info ConnectorGraphicsInfo ConnectorGraphicsInfo is an optional entity that can be used by a tool to describe graphical information for connecting objects (SequenceFlow, MessageFlow, Associations). Each connector in XPDL has a list of ConnectorGraphicsInfo, one for each tool that has saved the corresponding information in the XPDL file. If a tool chooses to use the ConnectorGraphicsInfo, it should select a tool id, which can be the name of the tool. Therefore multiple tools can work using the same XPDL file and displaying the process with a different presentation layout. DescriptionBorderColorColor of the border, expressed as a string. Tool specific and depends on ToolId.CoordinatesX and Y coordinates of points in the path. Tool specific and depends on ToolId.FillColorColor of the border, expressed as a string.ToolIdTool id. This may correspond to the name of the tool generating the XPDL file. Note that multiple NodeGraphicsInfo elements may appear in an element. This allows each tool to have its NodeGraphicsInfo, allowing for different tools using the same XPDL file to represent the element in totaly different ways. Each tool read and writes its own NodeGraphicsInfo based on its ToolId, and it leave untouch the NodeGraphicsInfo from oter tools.IsVisibleTrue indicates node should be shown.PageThe name of the page on which this node should be displayed.ShapeShape, expressed as a string: used to override BPMN shapesStyleLineStyle. Tool specific and depends on ToolId.Table  SEQ Table \* ARABIC 2: ConnnectorGraphicsInfo Extended Attributes Extended Attributes can be used in all entities. They allow vendors to extend the functionality of this specification to meet individual product needs. A vendor can use extended attributes in two maners: The anonymous extended attribute provides a name and a value for the extension without the need to qualify the extension with a namespace. Namespace qualified extensions can be used to extend XPDL elements by adding child elements or by adding attributes. Namespace qualified extensions can be validated against a vendor provided schema (see  REF _Ref106072367 \r \h 7.2.1.1  REF _Ref106072329 \h Vendor extensions). Anonymous Extended Attribute The anonymous extended attributes use the ExtendedAttribute element that can be used to add an extension with a name and a value. DescriptionNameUsed to identify the Extended AttributeValueValue of the extension.Table  SEQ Table \* ARABIC 3: Extended Attributes Namespace Qualified Extensions In order for a tool to add namespace-qualified extensions, it first needs to extend the XPDL schema to add the extensions in the places in which the XPDL schema allows the tool to add extensions. The new generated schema should contain in addition to the XPDL namespace the tool namespace. The resulting schema can be used in addition to the XPDL schema to validate XPDL 2.0 files. The extension places are marked in the XPDL schema by [namespace="##other" processContents="lax"]. In addition, the tool should include the namespace, and it should add the VendorExtension section in XPDL (see  REF _Ref106072367 \r \h 7.2.1.1  REF _Ref106072329 \h Vendor extensions), which contains a URI reference to the extended schema. A child element can be added to a XPDL element, by adding a child element to the ExtendAttributes under the XPDL element. An attribute to a XPDL element can also be added by just qualifying it by the vendor namespace. An example on how a vendor can create a schema with XPDL extensions is provided in section  REF _Ref113790272 \r \h 8.2  REF _Ref113790278 \h Extending XPDL Schema. Formal Parameters Formal parameters can be used as attributes in process and application. They are passed during invocation and return of control (e.g. of an invoked application). These are the invocation parameters. DescriptionData typeData type of the formal parameter. See Section  REF _Ref7409903 \w \h 7.13DescriptionTextual description of the formal parameterLengthThe length of the data. Used only for strings, to declare maximum length.IdIdentifier for the parameterNameName for the parameterIs ArrayIndicates if the parameter is an array or a single value parameterIndexIndex of the parameter (Deprecated)ModeIN Input Parameters OUT Output Parameters INOUT Parameters used as input and output Table  SEQ Table \* ARABIC 4: Formal Parameters Parameter passing semantics The parameter passing semantics is defined as: (a) Any read-only formal parameters (IN) are initialised by the value of the corresponding actual parameter in the call (an expression). This is pass-by-value semantics. (b) Any read/write formal parameters (INOUT) are initialised by the value of the corresponding actual (passed) parameter, which must be the identifier of a relevant data field entity. On completion of the process, the value of the formal out parameter is copied back to the original actual parameter (which must be the identifier of a relevant data field entity). This is copy-restore semantics. (c) Any write-only formal parameters (OUT) are initialised to zero (strings will be set to the empty string, complex data will have each element set to zero). On completion of the process, the value of the formal out parameter is copied back to the original actual parameter (which must be the identifier of a relevant data field entity). This is zero-restore semantics. Concurrency semantics Copying and restoring of parameters are treated as atomic operations; to avoid access conflicts from concurrent operations on relevant data field within the process instance these operations are serialized. Between copy and restore of (c) no locking is assumed and the returned parameter value will overwrite the local value (of the particular relevant data field item) at the time of the return call. Formal-actual parameter mapping The mapping of actual to formal parameters during invocation is defined by a parameter map list. The actual parameters are mapped 1:1 to the formal parameters in sequence, i.e. the first actual maps to the first formal, the second actual maps to the second formal etc. Type compatibility is required within the definitions and may be enforced by the run-time system. The effects of violation are locally defined and do not form part of this specification In case the actual parameter is an expression, the expression is evaluated and buffered by the engine, and the content of this buffer is used for formal-actual mapping. How the buffering and mapping is performed is outside the scope if this document. External Reference ExternalReference is a reference to an external definition of an entity. It can be used in DataTypes, Participant, and Application. DescriptionLocationIt specifies the URI of the document that defines the type.Namespace It allows specification of the scope in which the entity is defined.xrefIt specifies the identity of the entity within the external document.Table  SEQ Table \* ARABIC 5: External Reference Example 1: A FormalParameter that is defined by an XML schema: PO specification for abc.com Example 2: A DataField defined by a Java class: PO specification for abc.com Web Services An activity in a process may invoke a web service. The ExternalReference element may be used as a reference to applications and data types that are defined in Web Service (WSDL) documents. Example 3: A DataField whose data type is defined in a WSDL document: Example 4: An Application that is defined as an operation in a WSDL document: Assignment Data fields may be explicitly assigned new values during the execution of a process. This may happen at the start or termination of a process or an activity. Assignments may also be associated with transitions/sequence flow, in which case the assignments are performed when the particular transition/outgoing sequence flow is chosen. DescriptionTargetLvalue expression, normally the name of Data FieldExpressionRvalue expression in the scripting language specified for the package.AssignTimeSpecifies time of evaluation and assignment: Start or End of Process or Activity. Not relevant to transition/sequence flow.Table  SEQ Table \* ARABIC 6: Assignment Category The modeler MAY add one or more Categories to various elements, such as Process, Activity and Transition; which can then be used for purposes such as reporting and analysis. DescriptionIdId of the categoryNameName of CategoryTable  SEQ Table \* ARABIC 7: Category Artifact An Artifact is a graphical object that provides supporting information about the Process or elements within the Process. However, it does not directly affect the flow of the Process. Other examples of Artifacts include critical success factors and milestones. DescriptionIdId of the artifactNameName of the artifactArtifactTypeDataObject | Group | AnnotationDataObjectSee section  REF _Ref104951662 \r \h  \* MERGEFORMAT 7.1.7.2GroupName of the Group NodeGraphicsInfosSee section  REF _Ref104951682 \r \h  \* MERGEFORMAT 7.1.1.ObjectSee section  REF _Ref104951711 \r \h  \* MERGEFORMAT 7.1.7.1TextAnnotationVisible textual description.Table  SEQ Table \* ARABIC 8: Artifact Object Referred to by numerous other graphical elements. DescriptionNameName of the ObjectCategories A list of categories. See section  REF _Ref104951730 \r \h  \* MERGEFORMAT 7.1.6.DocumentationTextual DocumentationIdId of the objectTable  SEQ Table \* ARABIC 9: Object DataObject In BPMN, a Data Object is considered an Artifact and not a Flow Object. They are considered an Artifact because they do not have any direct affect on the Sequence Flow or Message Flow of the Process, but they do provide information about what the Process does. That is, how documents, data, and other objects are used and updated during the Process. While the name Data Object may imply an electronic document, they can be used to represent many different types of objects, both electronic and physical. As an Artifact, Data Objects generally will be associated with Flow Objects. An Association will be used to make the connection between the Data Object and the Flow Object. This means that the behavior of the Process can be modeled without Data Objects for modelers who want to reduce clutter. The same Process can be modeled with Data Objects for modelers who want to include more information without changing the basic behavior of the Process. In some cases, the Data Object will be shown being sent from one activity to another, via a Sequence Flow. Data Objects will also be associated with Message Flow. They are not to be confused with the message itself, but could be thought of as the payload or content of some messages. In other cases, the same Data Object will be shown as being an input, then an output of a Process. Directionality added to the Association will show whether the Data Object is an input or an output. Also, the state attribute of the Data Object can change to show the impact of the Process on the Data Object. DescriptionIdId of the data object.NameName is an attribute that is text description of the object.ProducedAtCompletionThe default value for this attribute is True. This means that the Output will be produced when an activity has been completed. If set to False, then the activity MAY produce the output (more than once; i.e. zero or more times) before it has completed.DataFieldsA list of data fields.RequiredForStartThe default value for this attribute is True. This means that the Input is required for an activity to start. If set to False, then the activity MAY start without the input, but MAY accept the input (more than once) after the activity has started.StateState is an optional attribute that indicates the impact the Process has had on the Data Object. Multiple Data Objects with the same name MAY share the same state within one Process.Table  SEQ Table \* ARABIC 10: Data Object Package Definition It is possible to define several processes within one package, which may share the same tools and participants. We recommend creating one package per business process which should contain all the necessary processes as well as all the associated tools and participants, although it is not required. It is also possible to define just parts of one process definition or common parts of several processes within one package (e.g. a participant list or a application list). DescriptionApplicationsA list of  REF _Ref7411657 \h Application Declarations. See section  REF _Ref7409805 \w \h 7.3ArtifactsA list of Artifacts that can be linked to the existing Flow Objects through Associations. See section  REF _Ref104951312 \r \h 6.4.7. and  REF _Ref104951343 \r \h 7.1.7.AssociationsA list of Associations which associate information and Artifacts with Flow Objects. See section  REF _Ref104971786 \r \h 7.10Conformance ClassStructural restriction on process definitions in this package. See section  REF _Ref7410130 \w \h 7.2.3Data FieldsA list of  REF _Ref104952473 \h Relevant data fields defined for the package. See section  REF _Ref104952524 \r \h 7.12Extended AttributesA list of vendor-defined extensions that may be added to the package. See section  REF _Ref7410439 \w \h 7.1.1External PackagesReference to another Package definition defined in a separate document.IdUsed to identify the package.MessageFlowsA list of MessageFlows which go between Pools or activities in two pools. See Section  REF _Ref104951270 \r \h 7.8NameText. Used to identify the package.Package HeaderA set of elements specifying package characteristics.ParticipantsA list of resources used in implementing processes in the package. See section  REF _Ref104951126 \r \h 7.11PartnerLinkTypesPartner link types for this package (see  REF _Ref113764465 \r \h 7.8.1)PoolsA list of Pools for the Package. See Section  REF _Ref104951054 \r \h 7.4Redefinable HeaderA set of elements and attributes used by both the Package and Process definitions. ScriptIdentifies the scripting language used in expressions.Type DeclarationsA list of  REF _Ref7412215 \h Data Types used in the package. See section  REF _Ref7411212 \w \h 7.13ProcessesA list of the Processes that comprise this package. See section  REF _Ref7411258 \w \h 7.5Table  SEQ Table \* ARABIC 11: Package Definition Package definition Header The package definition header keeps all information central to a package such as XPDL version, source vendor id, etc. DescriptionCost UnitUnits used in Simulation Data (Usually expressed in terms of a currency)CreatedCreation date of Package Definition.DescriptionTextual description of the packageDocumentationOperating System specific path- and filename of help file/description file.Priority UnitA text string with user defined semantics.VendorDefines the origin of this model definition and contains vendor's name, vendor's product name and product's release number.VendorExtensionsList of extensions by vendors. There is a vendor extension entry for each tool that provides extensions in this XPDL content.XPDL VersionVersion of this specification. The current value, for this specification, is 2.0.Table  SEQ Table \* ARABIC 12: Package Definition Header Attributes Vendor extensions Vendor extension is used for vendors to define extensions and provide a schema and a description for the extensions. For details, see section 7.1.2.2 Namespace Qualified Extensions. DescriptionToolIdIdentification of the tool adding this extension. It is the same value used in NodeGraphicsInfo ToolId. This value may be a URI.SchemaLocationAn URI indicating the location of the schema that can be used to validate the XPDL containing the extensions for the tool.ExtensionDescriptionAn URI indicating the location of a document describing the extensions provided by the schema in schemaLocation.Table  SEQ Table \* ARABIC 13: Vendor Extension -- Attributes Redefinable Header The redefinable header covers those header attributes that may be defined in the definition header and may be redefined in the header of any process definition. In case of redefinition, the scope rules hold. DescriptionAuthorName of the author of this package definition. Code pageThe codepage used for the text partsCountry keyCountry code based on ISO 3166. It could be either the three digits country code number, or the two alpha characters country codes.Publication StatusStatus of the Process Definition. UNDER_REVISION RELEASED UNDER_TEST Responsible(s)Participant, who is responsible for this process; the supervisor during run time Link to entity participant. Participant, who is responsible for this workflow of this Model definition (usually an Organisational Unit or a Human). It is assumed that the responsible is the supervisor during run time. Default: Initiating participant. VersionVersion of this Package Definition.Table  SEQ Table \* ARABIC 14: Redefinable Header Conformance Class Declaration The conformance class declaration allows description of the conformance class to which the definitions in this model definition are restricted. The specified class applies to all the contained process definitions, unless it is re-defined locally at the process definition level. DescriptionConformance ClassFULL-BLOCKED The network structure is restricted to proper nesting of SPLIT/JOIN and loops. LOOP-BLOCKED The network structure is restricted to proper nesting of loops. NON-BLOCKED There is no restriction on the network structure. This is the default. Table  SEQ Table \* ARABIC 15: Conformance Class Declaration Script The Script element identifies the scripting language used in XPDL expressions. A text expression may be used wherever an element is of type xsd:string. One could, for example, use an expression within Cost elements. An expression composed of formatted XML (e.g., MathML) may be used within the the ActualParameter or Xpression element (used within a Transition Condition). DescriptionTypeIdentifies the scripting language used in expressions. For consistency across implementations, when specifying a standard scripting language, it is recommended that the Type be selected from the following strings: text/javascript, text/vbscript, text/tcl, text/ecmascript, text/xml.VersionThis is the version of the scripting language.GrammarThis is a reference to a document that specifies the grammar of the language. It could be, for example, an XML schema, a DTD, or a BNF.Table  SEQ Table \* ARABIC 16: Script External Package External package reference allows referencing definitions in another Package definition or in other systems providing an Interface to the Process or Management system (e.g. a legacy Organisation Description Management Tool). DescriptionExtended AttributesOptional vendor-defined extensions to meet implementation needs. See section  REF _Ref104951837 \r \h 7.1.2hrefA Model Identifier. Logical reference to a ModelidThe id of externally referenced packageNameThe name given to the external packageTable  SEQ Table \* ARABIC 17: External Package Reference Application Declaration Application declaration is a list of all applications or tools required and invoked by the processes defined within the process definition or surrounding package. Tools may be defined (or, in fact, just named). This means, that the real definition of the tools is not necessary and may be handled by an object manager. The reason for this approach is the handling of multi-platform environments, where a different program (or function) has to be invoked for each platform. XPDL abstracts from the concrete implementation or environment (thus these aspects are not of interest at process definition time). DescriptionDescriptionShort textual description of the application.Extended AttributesOptional vendor-defined extensions to meet implementation needs. See section  REF _Ref104951870 \r \h 7.1.2External ReferenceA reference to an external specification of the application signature. See section  REF _Ref7412748 \w \h 7.1.4 Formal ParametersA list of parameters that is interchanged with the application via the invocation interface. See section  REF _Ref7412816 \w \h 7.1.3.IdUsed to identify the application definitionNameText used to identify an application (may be interpreted as a generic name of the tool).TypeThere are a number of standard Application Types. See section  REF _Ref111543735 \r \h 7.3.2Table  SEQ Table \* ARABIC 18: Application Declaration Invocation Parameters An Application declaration may have parameter definitions for the (invocation) parameters and also use them within other entities. Copying the invocation IN is treated as one atomic operation. The same holds for restoring the invocation OUT. Between these two operations no assumption is made about concurrency behaviour. Application Types Application Type contains several pieces of information required by common applications such as calling an EJB component or invoking a WebService. Support for a particular application type is not mandatory for the engine, but if the engine makes use of the listed technologies the additional information should be provided by Application Type. EJB Application type that defines information required to call a method of an EJB component. An EJB application has additional restrictions for formal parameters: there can be a maximum of one OUT formal parameter, and if it exists it has to be the last formal parameter, also there should be no INOUT formal parameters. With these restrictions IN formal parameters map directly to arguments of the method and the optional last OUT formal parameter becomes the return value of the method. DescriptionJndiNameJNDI name of the EJBHomeClassHome class fully qualified name MethodMethod that will be invokedTable  SEQ Table \* ARABIC 19: EJB Application Type Pojo Application type that defines information required to call method on local Java class. Formal Parameters restrictions are the same as for EJB application type. DescriptionClassfully qualified name of the classMethodMethod that will be invokedTable  SEQ Table \* ARABIC 20: POJO Application Type XSLT Application that uses XSL transformation on formal parameters. The Application should have one IN and one OUT formal parameter, or if the transformation transforms the formal parameter into a document in the same schema the application can have one INOUT formal parameter. DescriptionLocationLocation of the XSL transformationTable  SEQ Table \* ARABIC 21: XSLT Application Type Script Application that executes a script (expression) using formal parameters. The script should have access only to formal parameters of the application. DescriptionExpressionThe scriptTable  SEQ Table \* ARABIC 22: Script Application Type WebService Application that invokes a Web Service. All IN formal parameters should be mapped into content of the input message, all OUT formal parameters should be mapped to parts of the output message. DescriptionWebServiceOperationThe web service operation used to invoke this application.WebServiceFaultCatchProvides a way to catch faults generated by the applicationInputMsgNameThe name of inputMessage as defined in the WSDL which will help in uniquely identifying the operation to be invoked. OutputMsgNameThe name of inputMessage as defined in the WSDL which will help in uniquely identifying the operation to be invoke. Table  SEQ Table \* ARABIC 23: WebService Application Type BusinessRule Application that invokes a Business Rule. DescriptionRuleNameName of the Business RuleLocationLocation of the RuleTable  SEQ Table \* ARABIC 24: BusinessRule Application Type Form The standard does not decide which kind of a form layout should be used. The Form Application Type defines a place where all form related information should be stored. DescriptionFormLayoutOptional description of form layoutTable  SEQ Table \* ARABIC 25: Form Application Type Swimlanes Pool For a general description of SwimLanes, Pools and Lanes refer to section  REF _Ref104971686 \r \h 6.4.1. DescriptionBoundaryVisibleThis attribute defines if the rectangular boundary for the Pool is visible. Only one Pool on a page MAY have the attribute set to False.IdThe id of the Pool.LanesThe lanes in the pool. See section  REF _Ref104970853 \r \h 7.4.2NameThe name of the poolNodeGraphicsInfosSee section  REF _Ref104970870 \r \h 7.1.1.ObjectSee section  REF _Ref104970887 \r \h 7.1.7.1OrientationHORIZONTAL | VERTICALParticipantThe Modeler MUST define the Participant for a Pool. The Participant can be either a Role or an Entity. This defines the role that a particular Entity or Role the Pool will play in a Diagram that includes collaboration. <>ProcessThe Process attribute defines the Process that is contained within the Pool. Each Pool MAY have a Process.Table  SEQ Table \* ARABIC 26: Pools Lane DescriptionIdThe id of the Lane.NameThe name of the Lane.NodeGraphicsInfosSee section  REF _Ref104970911 \r \h 7.1.1.ObjectSee section  REF _Ref104970925 \r \h 7.1.7.1ParentLaneParentLane is an optional attribute that is used if the Lane is nested within another Lane. Nesting can be multi-level, but only the immediate parent is specified.ParentPoolThe Parent Pool MUST be specified. There can be only one Parent.Table  SEQ Table \* ARABIC 27: Lane Process Definition The Process Definition defines the elements that make up a process. It contains definitions or declarations, respectively, for Activity and, optionally, for Transition, Application, and Process Relevant Data entities. Attributes may be specified for administration relevant data like author, and version; for runtime relevant data like priority; and for BPR and simulation relevant data. A Process may run as an implementation of an activity of type subflow; in this case parameters may be defined as attributes of the process. Where a process definition includes input parameters and is instantiated by means other than a subflow call (for example by local event) the method for initializing any input parameters is locally defined. In such circumstances any relevant data field associated with the instantiated process definition, which is included within the parameter list will be initialized to the value specified in the default value (where specified). Where relevant data field is not passed as an input parameter, or initialized by default value the result is undefined. Similarly where a subflow terminates abnormally without returning out parameter values to the calling process, the result is undefined. In general the scope of the defined entity identifier and name is the surrounding entity. The identifier is unique in this scope. For the Process identifier and name the scope is the surrounding Package. When a process definition is instantiated it is necessary to determine which activity is the first (start) activity. There are a number of ways to do this. There may be only one activity that has no incoming transitions. A single activity may have its StartActivity attribute set to true. The process attributes DefaultStartActivtySet and/or DefaultStartActivity may be present. The process invocation may specify the StartActivitySet and/or StartActivity. Here we summarize the rules. The following logic applies: Unless otherwise specified in the process invocation (see ProcessRef  REF _Ref113869834 \r \h 7.6.5.4), DefaultStartActivtySet and/or DefaultStartActivity determine where the process will start executing. If present, DefaultStartActivitySetId must be the id of an Activity Set in the process If present, DefaultStartActivityId must be the id of a start activity In the Default Activity Set if thats present In the top level process activities otherwise If DefaultStartActivitySetId is present but not DefaultStartActivityId it is assumed that DefaultStartActivitySetId has exactly one start activity If neither is present it is assumed that the top level activities contain exactly one start activity It is assumed that a process invocation can designate StartActivitySetId and StartActivityId and thereby control where process execution starts. In particular sub process invocation can contain the information (see ProcessRef  REF _Ref113869980 \r \h 7.6.5.4). DescriptionAccessLevelThe Access level of a process may be either PUBLIC or PRIVATE. If PUBLIC the process may be invoked by an external system or application. A process with private access may only be invoked from a SubFlow Activity (see Section  REF _Ref104951932 \r \h 7.6.5.3.8). Use is optional and default is PUBLIC.ActivitiesA list of activities that comprise the process. See section  REF _Ref104951958 \r \h 7.6.ActivitySetsA list of self contained sets of activities and transitions. Used to represent a BPMN embedded subprocess.AdHocSee section  REF _Ref104952099 \r \h 7.5.8.AdHocOrderingSee section  REF _Ref104952112 \r \h 7.5.8AdHocCompletionConditionSee section  REF _Ref104952132 \r \h 7.5.8ApplicationsA list of  REF _Ref7411657 \h Application Declarations. See section  REF _Ref7409805 \w \h 7.3.AssignmentsA list of data field assignments. See section  REF _Ref104952165 \r \h 7.1.5Data FieldsA list of  REF _Ref104952618 \h Relevant data fields defined for the process. See section  REF _Ref104952644 \r \h 7.12.DefaultStartActivityIdIf present, DefaultStartActivityId must be the id of a start activity In the Default StartActivitySet if thats present In the top level process activities otherwiseDefaultStartActivitySetIdIf present, DefaultStartActivitySetId must be the id of an Activity Set in the process.EnableInstanceCompensationSee section  REF _Ref104952663 \r \h 7.5.7.Extended AttributesOptional vendor-defined extensions to meet implementation needs. See section  REF _Ref7410439 \w \h 7.1.1Formal ParametersA list of parameters that may be passed to the process. See section  REF _Ref7585838 \r \h 7.1.3.IdUsed to identify the process.NameText Used to identify the process.ObjectSee Section  REF _Ref104952683 \r \h 7.1.7.1ParticipantsA list of resources used in implementing the process. See section  REF _Ref104952720 \r \h 7.11.PartnerLinksPartner links used by this process (see  REF _Ref113764601 \r \h 7.8.2)Process HeaderA set of elements specifying process characteristics.ProcessTypeBPMN types: None, Private, Abstract, Collaboration. See section  REF _Ref104952738 \r \h 7.5.4.Redefinable HeaderA set of elements and attributes used by both the Package and Process definitions.StatusSee section  REF _Ref104952774 \r \h  \* MERGEFORMAT 7.5.5.SuppressJoinFailureSee section  REF _Ref104952787 \r \h 7.5.6.TransitionsA list of the transitions that connect the process activities. See section  REF _Ref7586048 \r \h 7.7.Table  SEQ Table \* ARABIC 28: Process Definition Process Definition Header The process definition header keeps all information specific for a process definition such as process version, priority, duration of validity, etc.