Issue 9324: No means to define Categories (bpmn-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com) Nature: Uncategorized Issue Severity: Summary: Several elements can have Categories attached. This is documented in Table 8-7 as "the Modeler may add one or more defined Categories"...However there is no mechanism for creating the 'defined categories' (as opposed to using them). Resolution: Revised Text: Section 8.1, Table 8.2, seventh row ("Group"), page 17 and Section 8.2, Table 8.3, first row on page ("Group"), page 26: a) First column: replace text with "Group (a box around a group of objects within the same category)" b) Second column: replace text with "A grouping of activities that are within the same category (“Group” on page XX). This type of grouping does not affect the Sequence Flow of the activities within the group. The category name appears on the diagram as the group label. Categories can be used for documentation or analysis purposes. Groups are one way in which categories of objects can be visually displayed on the diagram." Section 9.1, Table 9.2, second row ("Categories"), page 33 and Section B.3, Table B.3, second row ("Categories"), page 243--this section change for Issue 9377: c) First column: Change Categories type from "String" to "Category" d) Second column: replace text with "The modeler MAY add one or more defined Categories, which have user-defined semantics, and that can be used for purposes such as reporting and analysis. The details of Catogories is defined in “Category” on page XXX." Section 9.7.4 "Group," page 95 e) Replace first paragraph with: "The Group object is an Artifact that provides a visual mechanism to group elements of a diagram informally. The grouping is tied to the Category supporting element (which is an attribute of all BPMN elements). That is, a Group is a visual depiction of a single Category. The graphical elements within the Group will be assigned the Category of the Group. (Note -- Categories can be highlighted through other mechanisms, such as color, as defined by a modeler or a modeling tool)." Section 9.7.4 "Group," Table 9.38, page 97 and Section B.9.4, Table B.36, page 265: f) Replace row 1 with the following: CategoryRef : Category CategoryRef specifies the Category that the Group represents (Further details about the definition of a Category can be found in “Category on page XXX.”). The name of the Category provides the label for the Group. The graphical elements within the boundaries of the Group will be assigned the Category. g) Append the following row to Table 9.38, page 97: GraphicalElements (0-n) : Graphical Element The GraphicalElements attribute identifies all of the graphical elements (e.g., Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group. Section B.11.1, page 268: h) Add new Section of B.11.1 with the section title: "Category" i) Add a paragraph after the title: "The following table displays the set of attributes of a Category, which is used in the definition of attributes for all BPMN elements, and which extends the set of common BPMN element attributes (see Table B.2). Since a Category is also a BPMN element, a Category can have Categories to create a hierarchical structure of Categories." Add a new Table that has the following contents: j) The table title should be: "Category Attributes" k) The table should be: Attributes Description Name : String Name is an attribute that is text description of the Category and is used to visually distinguish the category. Actions taken: January 30, 2006: received issue April 19, 2007: closed issue Discussion: Resolution: A description of Groups is given in Section 9.7.4. A pointer to Section 9.7.4 was added to Table 8.2 and 8.3 through the resolution of Issue 9325. The resolution of this issue is dependent on the reorganization of the BPMN attributes and elements as resolved in Issue 9377. Both categories and groups are mechanisms for adding user-defined semantics to a model. This resolution proposes to align the category and group concepts in BPMN, thus removing redundancy and reducing confusion over when to use one versus the other. The category will now provide the semantic designation, while the group is merely one way in which a category can be visualized. A group MUST have exactly one category associated with it. The name of the category serves as the group label. All graphical elements within a group must be associated with the category that the group is associated with. Use Cases: o The user draws a group box around several graphical objects, and then associates the group with a category. The name of the category is shown on the diagram as the group name. All graphical objects within the group box will have the group’s category added to their category lists, if it is not already there. o The user associates one or more categories with any graphical object. The User then selects the category and chooses a visualization technique. One available technique would be to visualize as a group box. Tools can define additional visualization techniques, but some possibilities include: colors, lanes, and stereotype labels. It is up to the tool to ensure that the selected visualization can be applied End of Annotations:===== ubject: Issues on BPMN Date: Sun, 29 Jan 2006 21:17:59 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues on BPMN Thread-Index: AcYlXIlAAqRKeKvQTICFTOCuE//pqQ== From: "Pete Rivett" To: Cc: Issue G) No means to define Categories Several elements can have Categories attached. This is documented in Table 8-7 as "the Modeler may add one or more defined Categories"...However there is no mechanism for creating the 'defined categories' (as opposed to using them). Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Hello House, 135 Somerford Road, Christchurch, BH23 3PY, UK Tel: +44 (0)1202 491243 Fax: +44 (0)1202 491241 http://www.adaptive.com To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9324 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Sat, 21 Oct 2006 17:19:41 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/21/2006 18:19:41, Serialize complete at 10/21/2006 18:19:41 This is intended for Ballot 4 http://www.bpmn.org/FTF/Issues/Issue%209324.htm Note: at one point I thought we decided that a Group object needed to have the list of graphical elements that were contained within its boundaries. I wasn't sure, but I added this attribute in the resolution. If we don't need this attribute, then we can take it out. Issue 9324: No means to define Categories Description: Several elements can have Categories attached. This is documented in Table 8-7 as "the Modeler may add one or more defined Categories"...However there is no mechanism for creating the 'defined categories' (as opposed to using them). Suggested Resolution: Resolved: A description of Groups is given in Section 9.7.4. A pointer to Section 9.7.4 was added to Table 8.2 and 8.3 through the resolution of Issue 9325. The resolution of this issue is dependent on the reorganization of the BPMN attributes and elements as resolved in Issue 9377. Both categories and groups are mechanisms for adding user-defined semantics to a model. This resolution proposes to align the category and group concepts in BPMN, thus removing redundancy and reducing confusion over when to use one versus the other. The category will now provide the semantic designation, while the group is merely one way in which a category can be visualized. A group MUST have exactly one category associated with it. The name of the category serves as the group label. All graphical elements within a group must be associated with the category that the group is associated with. Use Cases: The user draws a group box around several graphical objects, and then associates the group with a category. The name of the category is shown on the diagram as the group name. All graphical objects within the group box will have the group.s category added to their category lists, if it is not already there. The user associates one or more categories with any graphical object. The User then selects the category and chooses a visualization technique. One available technique would be to visualize as a group box. Tools can define additional visualization techniques, but some possibilities include: colors, lanes, and stereotype labels. It is up to the tool to ensure that the selected visualization can be applied. Revised Text: Section 8.1, Table 8.2, seventh row ("Group"), page 17 and Section 8.2, Table 8.3, first row on page ("Group"), page 26: a) First column: replace text with "Group (a box around a group of objects within the same category)" b) Second column: replace text with "A grouping of activities that are within the same category (.Group. on page XX). This type of grouping does not affect the Sequence Flow of the activities within the group. The category name appears on the diagram as the group label. Categories can be used for documentation or analysis purposes. Groups are one way in which categories of objects can be visually displayed on the diagram." Section 9.1, Table 9.2, second row ("Categories"), page 33 and Section B.3, Table B.3, second row ("Categories"), page 243--this section change for Issue 9377: c) First column: Change Categories type from "String" to "Category" d) Second column: replace text with "The modeler MAY add one or more defined Categories, which have user-defined semantics, and that can be used for purposes such as reporting and analysis. The details of Catogories is defined in .Category. on page XXX." Section 9.7.4 "Group," page 95 e) Replace first sentence with: "The Group object is an Artifact that provides a visual mechanism to group elements of a Process informally. The grouping is tied to the Category supporting element for all BPMN elements. That is, a Group is a visual depiction of a single Category. All graphical elements within the Group will be assigned the Category of the Group. (Note -- Categories can be highlighted through other mechanisms, such as color, as defined by a modeler or a modeling tool)." Section 9.7.4 "Group," Table 9.38, page 97 and Section B.9.4, Table B.36, page 265: f) Replace row 1 with the following: CategoryRef : Category CategoryRef specifies the Category that the Group represents (Further details about the definition of a Category can be found in .Category on page XXX..). The name of the Category provides the label for the Group. All graphical elements within the boundaries of the Group will be assigned the Category. g) Append the following row to Table 9.38, page 97: GraphicalElements (0-n) : Object The GraphicalElements attribute identifies all of the objects (e.g., Events, Activities, Gateways, and Artifacts) that are contained within the Group. Section B.11.1, page 268: h) Add new Section of B.11.1 with the section title: "Category" i) Add a paragraph after the title: "The following table displays the set of attributes of a Category, which is used in the definition of attributes for all BPMN elements, and which extends the set of common BPMN element attributes (see Table B.2). Since a Category is also a BPMN element, a Category can have Categories to create a hierarchical structure of Categories." Add a new Table that has the following contents: j) The table title should be: "Category Attributes" k) The table should be: Attributes Description Name : String Name is an attribute that is text description of the Category and is used to visually distinguish the category. Subject: Re: Proposed Resolution for Issue 9324 To: Stephen A White Cc: bpmn-ftf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Suzette Samoojh Date: Mon, 23 Oct 2006 11:53:14 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 6.5.4|March 27, 2005) at 10/23/2006 11:53:15 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k9NFnXuU002737 Stephen A White wrote on 10/21/2006 08:19:41 PM: > e) Replace first sentence with: "The Group object is an Artifact > that provides a visual mechanism to group elements of a Process > informally. The grouping is tied to the Category supporting element > for all BPMN elements. That is, a Group is a visual depiction of a > single Category. All graphical elements within the Group will be > assigned the Category of the Group. (Note -- Categories can be > highlighted through other mechanisms, such as color, as defined by a > modeler or a modeling tool)." I don't think "... to group elements of a Process ... " is appropriate since, as I understand it, a Group can span Pools. Suggest replacing with "... to group graphical elements ...". > Section 9.7.4 "Group," Table 9.38, page 97 and Section B.9.4, Table > B.36, page 265: > f) Replace row 1 with the following: |----------+-------------------------------------------------------------| | CategoryR| CategoryRef specifies the Category that the Group represents | | ef : | (Further details about the definition of a Category can be | | Category | found in ?Category on page XXX.?). | | | The name of the Category provides the label for the Group. | | | All graphical elements within the boundaries of the Group | | | will be assigned the Category. | |----------+-------------------------------------------------------------| I'm not clear on why we need this new attribute. A Group is a GraphicalObject and thus inherits the Categories attribute. Is the new attribute intended to make it clear that the Group is associated with a single Category? If so, couldn't we achieve that by merely adding a constraint on how a Group uses the Categories attribute? > g) Append the following row to Table 9.38, page 97: |-------------+----------------------------------------------------------| | GraphicalEle| The GraphicalElements attribute identifies all of the | | ments (0-n) | objects (e.g., Events, Activities, Gateways, and | | : Object | Artifacts) that are contained within the Group. | |-------------+----------------------------------------------------------| Recommend we refrain from using the term "contained", since it implies containment from a metamodel point-of-view. Suggest we remove the word altogether, so the description becomes "... that are within the Group". Suzette To: bpmn-ftf@omg.org, Suzette Samoojh , "Karl Frank" Subject: Re: Proposed Resolution for Issue 9324 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Mon, 23 Oct 2006 13:48:04 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/23/2006 14:48:05, Serialize complete at 10/23/2006 14:48:05 Trying to address both Karl's and Suzette's comments... Note: the draft spec pdf was not synched with the resolution text. I'll post an update later today with a new version of the ballot First a new draft of the group description.. Section 9.7.4 "Group," page 95 e) Replace first paragraph with: "The Group object is an Artifact that provides a visual mechanism to group elements of a diagram informally. The grouping is tied to the Category supporting element (which is an attribute of all BPMN elements). That is, a Group is a visual depiction of a single Category. The graphical elements within the Group will be assigned the Category of the Group. (Note -- Categories can be highlighted through other mechanisms, such as color, as defined by a modeler or a modeling tool)." Suzette wrote: " I don't think "... to group elements of a Process ... " is appropriate since, as I understand it, a Group can span Pools. " "group elements of a process.." was changed to "group elements of a diagram..." Suzette wrote: "I'm not clear on why we need this new attribute [CategoryRef]..." Since a Group is a Graphical Element, it can also be part of a larger Group, and thus needs to have the full capabilities of the Category attribute (inherited from BPMN Element). CategoryRef provides the mechanism to identify the Category that the Group represents without restricting the Groups own Category capabilities. Also, the original proposal had the visualization defined at for the Category. But this would require that all elements of that Category must have a group box around it. A modeler may just want to group a few objects in part of diagram for a particular Category (leaving other objects with the same Category without a surrounding Group box). Suzette wrote: "I didn't notice earlier that the new GraphicalElements attribute is of type Object" I've changed it to be of type "Graphical Element," which along with "Supporting Element" is a type of BPMN Element. This impacted some of Issue 9377 for the diagrams to be added and requires that a brief section that defines "Graphical Element" should be added. I also noticed that the "Source" and "Target" attributes of "Connecting Element" are also of type "Object." These shoudl also be changed to "Graphical Element." This will be tacked on to Issue 9377. Karl wrote: "The phrase "All graphical elements within a group must be ..." suggests (by the usual interpretation of "all" in logic) that a group may have other elements that are NOT graphical." "All graphical elements..." will be changed to "The graphical elements..." I don't think that non-graphical elements (which include assignments, expressions, roles, inputs--all the supporting elements) apply to this. Karl wrote: "The members of groups must [by logical implication] be graphical elements, capable of "highlighting." If this implication is intended, it must be stated explicitly, not left to the reader to figure out, and then wonder whether it was intended" The change of GraphicalElements from "Object" to "Graphical Elements" should take care of this. Also in the description for the CategoryRef attribute, the text "All graphical elements within..." will be changed to "The graphical elements within..." The only graphical elements should be associated with the Category (when grouped). Suzette wrote: "Recommend we refrain from using the term "contained", since it implies containment from a metamodel point-of-view" The text description for the GraphicalElements attribute of the Group will change "that are contained within the Group" to "that are within the boundaries of the Group" Karl wrote: "It still retains the explicit description of "draws a group box around several graphical elements" as part of the core text, and only adds a note in an obscure spot allowing other methods of "highlighting". " and "This the placement of the text about "draw[ing] a group box" is guaranteed to give the impression that this is the "standard" way, and that "other mechanisms are, at best, permitted."" A Group is an explicit "box" around a set of objects. I don't see why we would not say that. Sentences two and three of the revised text above make it clear that the Group is representing a defined Category. We also don't want to say too much about other Category highlighting mechanisms since they are not part of the standard and are extension mechanisms. A note seems appropriate. Suzette Samoojh 10/23/2006 09:36 AM To bpmn-ftf@omg.org, Stephen A White/Irvine/IBM@IBMUS cc Subject Re: Proposed Resolution for Issue 9324 Following up on one of Karl's comments ... I didn't notice earlier that the new GraphicalElements attribute is of type Object |-------------+-----------------------------------------------------------| | GraphicalEle| The GraphicalElements attribute identifies all of the | | ments (0-n) | objects (e.g., Events, Activities, Gateways, and | | : Object | Artifacts) that are contained within the Group. | |-------------+-----------------------------------------------------------| Should it be? I don't think this is appropriate, and I would agree with Karl's assessment that we're leaving the question open of what a Group can contain. I recommend changing the type to "GraphicalObject". If a Group is really just a graphical mechanism, then only graphical elements should be grouped. And we should be explicit about it instead of implying it (through the attribute name). Suzette -------------------------------------------------------------------------------------- Suzette Samoojh/Toronto/IBM wrote on 10/23/2006 11:53:14 AM: > Stephen A White wrote on 10/21/2006 08:19:41 PM: > > > e) Replace first sentence with: "The Group object is an Artifact > > that provides a visual mechanism to group elements of a Process > > informally. The grouping is tied to the Category supporting element > > for all BPMN elements. That is, a Group is a visual depiction of a > > single Category. All graphical elements within the Group will be > > assigned the Category of the Group. (Note -- Categories can be > > highlighted through other mechanisms, such as color, as defined by a > > modeler or a modeling tool)." > > I don't think "... to group elements of a Process ... " is > appropriate since, as I understand it, a Group can span Pools. > Suggest replacing with "... to group graphical elements ...". > > > Section 9.7.4 "Group," Table 9.38, page 97 and Section B.9.4, Table > > B.36, page 265: > > f) Replace row 1 with the following: > > CategoryRef : Category > > CategoryRef specifies the Category that the Group represents > (Further details about the definition of a Category can be found in > ?Category on page XXX.?). > The name of the Category provides the label for the Group. All > graphical elements within the boundaries of the Group will be > assigned the Category. > > I'm not clear on why we need this new attribute. A Group is a > GraphicalObject and thus inherits the Categories attribute. Is the > new attribute intended to make it clear that the Group is associated > with a single Category? If so, couldn't we achieve that by merely > adding a constraint on how a Group uses the Categories attribute? > > g) Append the following row to Table 9.38, page 97: > > GraphicalElements (0-n) : Object > > The GraphicalElements attribute identifies all of the objects (e.g., > Events, Activities, Gateways, and Artifacts) that are contained > within the Group. > > Recommend we refrain from using the term "contained", since it > implies containment from a metamodel point-of-view. Suggest we > remove the word altogether, so the description becomes "... that are > within the Group". > Suzette Subject: RE: Draft of Ballot 4 - 9324 Date: Sun, 22 Oct 2006 07:00:55 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft of Ballot 4 - 9324 Thread-Index: Acb1nN5D1UwJiknOSEqDi6JBq3cjdQAQoNwR Priority: Urgent From: "Karl Frank" To: "Stephen A White" , X-OriginalArrivalTime: 22 Oct 2006 14:00:56.0535 (UTC) FILETIME=[7ECBFE70:01C6F5E2] X-TM-AS-Product-Ver: SMEX-7.0.0.1499-3.6.1039-14764.000 X-TM-AS-Result: No--17.601500-8.000000-1 The proposed rewording of 9324 carries many problems forward. It still retains the explicit description of "draws a group box around several graphical elements" as part of the core text, and only adds a note in an obscure spot allowing other methods of "highlighting". We had an extended discussion in Boston about the many problems this explicit description is causing. The proposed resolution attempts to address those problems by adding a note: "(Note -- Categories can be highlighted through other mechanisms, such as color, as defined by a modeler or a modeling tool)." This addition is inadequate to solve the problem, as explained next. 1. The members of groups must [by logical implication] be graphical elements, capable of "highlighting." If this implication is intended, it must be stated explicitly, not left to the reader to figure out, and then wonder whether it was intended. 2. This the placement of the text about "draw[ing] a group box" is guaranteed to give the impression that this is the "standard" way, and that "other mechanisms are, at best, permitted." 3. The phrase "All graphical elements within a group must be ..." suggests (by the usual interpretation of "all" in logic) that a group may have other elements that are NOT graphical. If all elements within a group are (according to the spec) necessarily graphical, then the qualification "graphical" in this sentence must be removed, as it is misleading. If the spec means to allow for non-graphical members, it must define a way to add such elements to a group. Generalizing from the above, the appearance of GUI scenarios (drawing boxes and "highlighting") within a normative language spec, is IMO unacceptable, and the reason is that it causes problems such as those explained above. I wonder how the UML Profile for BPMN, which is supposed to solve our interchange problems with BPMN, has handled the issues explained above, 1 thru 3? - Karl Frank -------------------------------------------------------------------------------- From: Stephen A White [mailto:wstephe@us.ibm.com] Sent: Sun 10/22/2006 1:40 AM To: bpmn-ftf@omg.org Subject: Draft of Ballot 4 Below is a draft of Ballot 4 Please review for format and content, and provide feedback. We have a short turn-around on this one, even though there is a lot of content. We need to resolve this and prepare the final report by November 13. The final Ballot will be distributed on October 25 Then, there will be two weeks, ending November 8, in which to vote after the final ballot has been sent. You can see the proposed changes in a draft version of the specification (http://www.bpmn.org/FTF/Issues/Voting/BPMN%20V1-1%20Draft%20for%20Issue%20Ballot%204.pdf) and in a draft Element and Attribute Diagram (http://www.bpmn.org/FTF/Issues/Voting/BPMN%20Elements%20and%20Attributes%201-1%20OMG%20Draft%20--%20Balot%204.jpg) -Steve BPMN FTF Test Ballot 4 -- DRAFT http://www.bpmn.org/FTF/Issues/Voting/FTF%20Issues%20Ballot%204.htm The Ballot will close on close of business November 8, 2006 Note: only the votes of official FTF voting members will be counted (see here for the list of voting members: http://www.omg.org/techprocess/meetings/schedule/BPMN_FTF.html#Voting_List_Deadline) The results of voting will be maintained here: http://www.bpmn.org/FTF/FTF%20Issues.htm Please vote Yes/No/Abstain for all of the following Issues: Resolution Vote (9318): Yes ___ No ___ Abstain ___ Resolution Vote (9319): Yes ___ No ___ Abstain ___ Resolution Vote (9324): Yes ___ No ___ Abstain ___ Resolution Vote (9326): Yes ___ No ___ Abstain ___ Resolution Vote (9328): Yes ___ No ___ Abstain ___ Resolution Vote (9329): Yes ___ No ___ Abstain ___ Resolution Vote (9355): Yes ___ No ___ Abstain ___ Resolution Vote (9356): Yes ___ No ___ Abstain ___ Resolution Vote (9357): Yes ___ No ___ Abstain ___ Resolution Vote (9367): Yes ___ No ___ Abstain ___ Resolution Vote (9376): Yes ___ No ___ Abstain ___ Resolution Vote (9377): Yes ___ No ___ Abstain ___ Resolution Vote (9410): Yes ___ No ___ Abstain ___ Issue descriptions and resolutions are below... List of Issues for Vote, Ordered by Number Issue Brief Description Resolution Vote 9318 Attributes not explained with respect to Notation Description: Most elements have a section called 'attributes' - but nowhere is it explained how these are related to the Notation being specified. Is it expected that each shape will have a 'property sheet' allowing these attributes to be viewed and edited? The end of Section 7.1.1 states "Thus, the graphic elements of BPMN will be supported by attributes that will supply the additional information required". In many cases though the attributes described include information that is redundant with the diagrammatic representation e.g. Name (in several places including 9.6.1) and ParentPool and ParentLane for Lane in section 9.6.3. In general Appendix B has more of the flavor of a metamodel or an interchange definition than a Notation. Resolution: Defer: This issue will be resolved during the next BPMN FTF. Revised Text: None Yes No Abstain 9319 Unclear whether BPEL is part of Conformance Description: Issue B) Unclear whether BPEL is part of Conformance Section 6.2 states "The BPMN specification supports for the following specifications is a normative part of the BPMN specification: BPEL4WS." but BPEL is not mentioned in the Conformance section 2 Resolution: Resolved: Section 2 of the specification will be updated to clarify the conformance for BPEL and more general conformance considerations. Revised Text: Section 1, page 1: a) Add a new paragraph after paragraph 3: "This version of the specification does not specify a mechanism for exchange of BPMN diagrams. Furthermore, this version of the specification does not specify a mechanism for the exchange of the semantic model of a process depicted by a BPMN diagram." Section 2, page 1: b) Replace this section with the following text: "An implementation claiming conformance to this specification shall comply with all of the requirements set forth in subclauses 2.1, 2.2 and 2.3 below. 2.1 Visual Appearance A key element of BPMN is the choice of shapes and icons used for the graphical elements identified in this specification. The intent is to create a standard visual language that all process modelers will recognize and understand. An implementation that creates and displays BPMN Diagrams shall use the graphical elements, shapes and markers specified in clauses 9-10 as the diagrammatic elements that represent the specified concepts. Note: There is flexibility in the size, color, line style, and text positions of the defined graphical elements. The following extensions to a BPMN Diagram are permitted: New markers or indicators MAY be added to the specified graphical elements. These markers or indicators could be used to highlight a specific attribute of a BPMN element or to represent a new subtype of the corresponding concept. (See also 2.4 below) A new shape representing a kind of Artifact MAY be added to a Diagram, but the new Artifact shape SHALL NOT conflict with the shape specified for any other BPMN object or marker. Graphical elements MAY be colored, and the coloring may have specified semantics that extend the information conveyed by the element as specified in this standard. The line style of a graphical element MAY be changed, but that change SHALL NOT conflict with any other line style required by this specification. An extension SHALL NOT change the specified shape of a defined graphical element or marker. (e.g., changing a square into a triangle, or changing rounded corners into squared corners, etc.). 2.2 Structural Conformance An implementation that creates and displays BPMN diagrams shall conform to the specifications and restrictions in Clauses 9-10 with respect to the connections and other diagrammatic relationships between graphical elements. Where permitted or required connections are specified as conditional and based on attributes of the corresponding concepts, the implementation shall ensure the correspondence between the connections and the values of those attributes. In general, these connections and relationships have specified semantic interpretations, which specify interactions among the process concepts represented by the graphical elements. Conditional relationships based on attributes represent specific variations in behavior. Structural conformance therefore guarantees the correct interpretation of the diagram as a specification of process, in terms of flows of control and information. Throughout the document, structural specifications will be appear in paragraphs using a special shaped bullet: ? (a filled diamond) Example: ? A Task MAY be a target for Sequence Flow; it can have multiple incoming Flows. An Incoming Flow MAY be from an alternative path and/or a parallel paths. 2.3 Semantic Elements This specification defines many semantic concepts used in defining processes, and associates them with graphical elements, markers, and connections. To the extent that an implementation provides an interpretation of the BPMN diagram as a semantic specification of process, the interpretation shall be consistent with the semantic interpretation herein specified. Note -- The intent here is that a BPMN diagram used as a "workflow specification" will have the interpretation specified in this standard, somewhat extended or narrowed by the characteristics of the workflow system. Similarly, when a BPMN diagram used as a specification for the processes and interactions of software agents, any generated software will reflect the semantics of the diagram as specified in this standard, possibly narrowed or extended by the characteristics of the software implementation. 2.4 Attributes and Properties This specification defines a number of attributes and properties of the semantic objects represented by the graphical elements, markers, and connections. Some of these attributes are purely representational and are so marked, and some have required representations. Some attributes are specified as mandatory, but have no representation or only optional representation. And some attributes are specified as optional. For every attribute or property that is specified as mandatory, a conforming implementation SHALL provide some mechanism by which values of that attribute or property can be created and displayed. This mechanism SHALL permit the user to create or view these values for each BPMN object specified to have that attribute or property. Where a graphical representation for that attribute or property is specified as required, that graphical representation SHALL be used. Where a graphical representation for that attribute or property is specified as optional, the implementation MAY use either a graphical representation or some other mechanism. If a graphical representation is used, it SHALL be the representation specified. Where no graphical representation for that attribute or property is specified, the implementation MAY use either a graphical representation or some other mechanism. If a graphical representation is used, it SHALL NOT conflict with the specified graphical representation of any other BPMN object. 2.5 Extended and Optional Elements A conforming implementation is not required to support any element or attribute that is specified herein to be non-normative or informative. In each instance in which this specification defines a feature to be "optional", it specifies whether the option is in: how the feature shall be displayed, whether the feature shall be displayed whether the feature shall be supported. A conforming implementation is not required to support any feature whose support is specified to be optional. If an implementation supports an optional feature, it SHALL support it as specified. A conforming implementation SHALL support any "optional" feature for which the option is only in whether or how it shall be displayed." Yes No Abstain 9324 No means to define Categories Description: Several elements can have Categories attached. This is documented in Table 8-7 as "the Modeler may add one or more defined Categories"...However there is no mechanism for creating the 'defined categories' (as opposed to using them). Resolution: Resolved: A description of Groups is given in Section 9.7.4. A pointer to Section 9.7.4 was added to Table 8.2 and 8.3 through the resolution of Issue 9325. The resolution of this issue is dependent on the reorganization of the BPMN attributes and elements as resolved in Issue 9377. Both categories and groups are mechanisms for adding user-defined semantics to a model. This resolution proposes to align the category and group concepts in BPMN, thus removing redundancy and reducing confusion over when to use one versus the other. The category will now provide the semantic designation, while the group is merely one way in which a category can be visualized. A group MUST have exactly one category associated with it. The name of the category serves as the group label. All graphical elements within a group must be associated with the category that the group is associated with. Use Cases: The user draws a group box around several graphical objects, and then associates the group with a category. The name of the category is shown on the diagram as the group name. All graphical objects within the group box will have the group.s category added to their category lists, if it is not already there. The user associates one or more categories with any graphical object. The User then selects the category and chooses a visualization technique. One available technique would be to visualize as a group box. Tools can define additional visualization techniques, but some possibilities include: colors, lanes, and stereotype labels. It is up to the tool to ensure that the selected visualization can be applied. Revised Text: Section 8.1, Table 8.2, seventh row ("Group"), page 17 and Section 8.2, Table 8.3, first row on page ("Group"), page 26: a) First column: replace text with "Group (a box around a group of objects within the same category)" a) Second column: replace text with "A grouping of activities that are within the same category (.Group. on page XX). This type of grouping does not affect the Sequence Flow of the activities within the group. The category name appears on the diagram as the group label. Categories can be used for documentation or analysis purposes. Groups are one way in which categories of objects can be visually displayed on the diagram." Section 9.1, Table 9.2, second row ("Categories"), page 33 and Section B.3, Table B.3, second row ("Categories"), page 243--this section change for Issue 9377: a) First column: Change Categories type from "String" to "Category" a) Second column: replace text with "The modeler MAY add one or more defined Categories, which have user-defined semantics, and that can be used for purposes such as reporting and analysis. The details of Catogories is defined in .Category. on page XXX." Section 9.7.4 "Group," page 95 a) Replace first sentence with: "The Group object is an Artifact that provides a visual mechanism to group elements of a Process informally. The grouping is tied to the Category supporting element for all BPMN elements. That is, a Group is a visual depiction of a single Category. All graphical elements within the Group will be assigned the Category of the Group. (Note -- Categories can be highlighted through other mechanisms, such as color, as defined by a modeler or a modeling tool)." Section 9.7.4 "Group," Table 9.38, page 97 and Section B.9.4, Table B.36, page 265: a) Replace row 1 with the following: CategoryRef : Category CategoryRef specifies the Category that the Group represents (Further details about the definition of a Category can be found in .Category on page XXX..). The name of the Category provides the label for the Group. All graphical elements within the boundaries of the Group will be assigned the Category. a) Append the following row to Table 9.38, page 97: GraphicalElements (0-n) : Object The GraphicalElements attribute identifies all of the objects (e.g., Events, Activities, Gateways, and Artifacts) that are contained within the Group. Section B.11.1, page 268: a) Add new Section of B.11.1 with the section title: "Category" a) Add a paragraph after the title: "The following table displays the set of attributes of a Category, which is used in the definition of attributes for all BPMN elements, and which extends the set of common BPMN element attributes (see Table B.2). Since a Category is also a BPMN element, a Category can have Categories to create a hierarchical structure of Categories." Add a new Table that has the following contents: a) The table title should be: "Category Attributes" a) The table should be: Attributes Description Name : String Name is an attribute that is text description of the Category and is used to visually distinguish the category. Yes No Abstain 9326 Unclear semantics of Group Description: Table 8.1: unclear if a Group groups Activities or objects in general. Can it have a name? Resolution: Resolved: The concepts of Categories and Groups will be combined. Issue 9324 will specify the required changes to the specification, so no further changes are required for this issue. Revised Text: None Yes No Abstain 9328 Sequence Flow is not a Flow Object Description: It seems a bit odd that a Sequence Flow is not a Flow Object as its name would appear otherwise: actually the term Flow Object is probably the one that misleads. Resolution: Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Revised Text: None Yes No Abstain 9329 Unclear what complete syntax is for an Attribute Description: 6.1.1 should show the complete syntax for an attribute e.g. as BNF. Resolution: Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Revised Text: None Yes No Abstain 9355 Which is it, Core Elements, or Flow Objects? Description: Note: This issue is vaguely related to 9321 See section 8.1 "BPD Core Element Set" starting on page 15 of 06-01-01 The text presentation is organized according to four "basic categories" and gives the impresion that some semantic or syntactic commonality underlies each of the four categories. The category Flow Objects are listed on page 15 as bullet items. but the table 8.1 repeats the same list, but now calling them "Core Modelng Elements", and the category "Flow Objects" has been forgotten. This is confusing. It is additionally confusing to have separate lists of "Core Modeling Elements", "Core Resolution: Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Revised Text: None Yes No Abstain 9356 Is it really the Complete Set? Description: Section 8.2 is entitled "BPD Complete Set", and Table 8.3 is "BPD Complete Element Set", but the text says that that what the table displays is just "... a more extensive list" showing what "...could be depicted through a business process modeling notation". If it is really the complete set, it is misleading to describe it in this way. I guess the topic is not what could be depicted with a business process modeling notation, but rather the full extent of what is provided for with the BPMN notation as specified in this document. This issue suggest that the provision for extending the notation should not be scattered (as it is now) throughout the document, so that better clarity can be achieved between the notation provided in the spec, and the possiblity of user extensions of that notation. The problem now is that the possiblilty of adding new notations is getting mixed in with the purported presentation of the COMPLETE SET. Resolution: Resolved: A more accurate name for Section 8.2 and Table 8.3 would be "BPD Extended Element Set." Revised Text: Section 8.2, page 18: a) Change the section title to "BPD Extended Set" Section 8.2, page 18, Table 8.3: b) Change the table title to "BPD Extended Set" Yes No Abstain 9357 Need consistent terminology for Categories, Core Elements Description: The text presentation on page 15 of 06-01-01 (section 8.1) introduces four "basic categories" of Core Modeling Elements. compare that with Section 9.1, the text preceding Table 9.1, which reads in part >>>> "BPMN graphical objects (Flow Objects, Swimlanes, Artifacts and Connecting Objects)" These same four were earlier said to be the basic Categories aka the Core Modeling Elements. Now they are said to be the four "graphical objects". It seems likely that authors of different parts of the text were agreed that this list of four was speciallly important, but that they did not use the same terminology for them. They should consistently be termed "categories", "core elements" or "the BPMN Graphical Objects", but not a mix of all 3 terminologies. Since these four categories turn up in so many contexts, they invite close study, and their seemng importance -- at least in the view of the authors of the spec -- suggests that the metamodel of the BPMN domain should recognize them as important metaclasses. If this implication is not intended, then the text should get rid of these "categories". Resolution: Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Revised Text: None Yes No Abstain 9367 BPMN Adopted Spec issue - Clarify behavior of Error intermediate event Description: I feel that the definition of the behavior of the Error intermediate Event is unclear in the BPMN Adopted Specification. We implemented its behavior to closely model the / in BPEL, but upon discussion with one of our customers and then with Steve it appears that our interpretation of the spec is not what was intended by its authors. Error intermediate Events are discussed with any detail in the following places in the spec: -------------------------- Table 9.6 (p. 41) describes the End event and says - "This type of End indicates that a named Error should be generated. This Error will be caught by an Intermediate Event within the Event Context." Table 9.8 (p. 45) describes the Error intermediate event - "This is used for error handling--both to set (throw) and to react to (catch) errors. It sets (throws) an error if the Event is part of a Normal Flow. It reacts to (catches) a named error, or to any error if a name is not specified, when attached to the boundary of an activity." Table 9.9 (p. 46, 47) has Error intermediate event attributes described. The behavior described there relates to the ErrorCode. Text on p 59-60 describes its role in modeling a Hazard in a Business Transaction. Text on p 76 mentions it can be a target of an Event-based Gateway, although on p. 78 under "Changes since the 1.0 draft version" it says that Error was removed as a possible target. I believe the text on p 76 is an editing error. Text on page 130-131 describes the "Event Context", mentioned in table 9.6. Text on that page in the last paragraph explicitly compares Error to the BPEL4WS fault, and goes on in that paragraph to describe the role of the ErrorCode. Table 11.5 (p. 141) mentions that Error end events map to BPEL throw elements, again tying it to the notion of faults. Table 11.10 (p. 145) describes the mapping to BPEL for intermediate Error event, which proposes that a boundary event be mapped to a within a that encompasses the activity. ------------------------ From this somewhat limited description, we chose to implement Error as a strictly hierarchical faulting mechanism, as it is in BPEL as well as most programming languages, and which seems a direct consequence of the mapping in Table 11.10. However, in subsequent discussion I have learned it was the intention of the authors that Errors be "subscribed" to in a global scope, and that they will be responded to from any activie location in the process, but that the highest "parent" activity in a subprocess hierarchy will supersede (and terminate) any lower-level Error intermediate events. (This is my interpretation of an email thread with Steve on this subject that is not crisp enough to include verbatim in this issue. I may have interpreted it wrongly, however.) If the intention of BPMN is to allow Error to be used as a parallel- thread signaling mechanism (supporting a "first one done wins" pattern, for example) as well as a hierarchical faulting mechanism (where the scope in which a thrown Error can be caught is limited to the hierarchy of parents of the activity that causes it, including the activity itself) then the behavior of a number of ambiguous topologies need to be clarified in the spec. Also, I believe the mapping to BPEL is incorrect for the signaling use, and that for some configurations a correct mapping may not exist. In any event, clarifying the scope of the Event Context with respect to the behavior of the Error event seems necessary. ------------------------- My proposed resolution will be for the text to make it clear that Error can only be caught by the activity that causes it or one of its parents. There are several other alternatives to use for signaling between parallel sequence flows, including our suggestion to our customers that the Rule event be used. Resolution: Resolved: The text will be modified to specify that an Error can only be caught by the activity that causes it or one of its parents. Revised Text: Section 9.3.3 "End," page 41, Table 9.6: a) Third row, second column: Replace current text with: "This type of End indicates that a named Error should be generated. The Error will be caught by the Error intermediate event with the same ErrorCode or no ErrorCode which is on the boundary of the nearest enclosing parent activity (hierarchically). The behavior of the process is unspecified if no activity in the has such an Error intermediate event. The system executing the process may define additional Error handling in this case, a common one being termination of the process instance." Section 9.3.4 "Intermediate," page 45, Table 9.8: Fourth row, second column: a) Delete the first two sentences. a) Change the first word of the next sentence from "It" to "This" Section 9.3.4 "Intermediate," page 46, Table 9.9 and Section B.5.4, page 248, Table B.8: Row on page for "Error Code," second column: a) Delete the first two sentences. Note, this description will be moved for the proposal to resolved Issue 9377. The description will be in a new table for the Error Event Detail. But the same two sentences will be deleted. Section 9.3.4 "Intermediate": Page 47, Last Bullet item on page: a) Delete the text ", Error" (was ", Exception") from the first sentence. a) Replace the text ", and Multiple" with the text ", Error, and Multiple" in the second sentence. Page 48, Second Bullet item on page: a) Delete the text ", Error" from the first sentence. Section 9.5.2 "Exclusive Gateways," subsection "Event-Based," page 76, first paragraph (continued from previous page): a) Delete the text " and Errors" from the end of the last sentence. Section 10.2.2 "Exception Flow," page 131, first paragraph after Figure 10.53: a) Append the paragraph with the text "An exception to this is the Error event, which will only respond to Error triggers generated within the activity or in a subprocess of that activity" Yes No Abstain 9376 Fundamental semantic model of token flows Description: Currently there is no description of the fundamental semantic model of token flows in the spec. Clearly it is based on a variety of petri net; however a description of the particular semantics assumed in BPMN could be very useful in reading the spec. Such a description should be formal in the sense that it should be mathematically clear what the procedural semantics of BPMN is. Resolution: Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this Issue will be deferred and handled by work on a later version of BPMN. Revised Text: None Yes No Abstain 9377 Optional description attribute Description: Every element in a diagram should have an optional description attribute. This is in addition to the name and properties' attributes. One issue to decide is whether a description attribute should have structure - whether it refers to a machine-processable description or a human oriented description. Essentially both are important. Resolution: Resolved: All elements will be given an optional Documentation attribute. The organization of BPMN elements and attributes will be modified to accomplish this and to clean up additional problems found with the way attributes are organization and presented in the specification. Also, class diagrams of the elements and attributes will be added to Appendix B to aid in the readers understanding of the contents of that appendix. Revised Text: Set up the Elements so that there is a high-level BPMN Element element so that both graphical and supporting objects share the same basic attributes, which are id, category, and documentation: Create the BPMN Element element: Section 9.1 "Common Graphical Object Attributes," page 33 and Section B.3 "Common Graphical Object Attributes," page 243: a) Change the section title to:"Common BPMN Element Attributes" b) Change the first sentence of the section to:"The following table displays a set of common attributes for BPMN Elements (Graphical Elements and Supporting Elements)." c) Change the table title to:"Common BPMN Element Attributes" d) for Section 9.1: add the following paragraph after the table: "These attributes are used for Flow Objects (Section 9.2, .Common Flow Object Attributes,. on page XX), Connecting Objects (Section 10.1, .Graphical Connecting Objects,. on page XX), Swimlanes (Section 9.6, .Swimlanes (Pools and Lanes),. on page XX), Artifacts (Section 9.7, .Artifacts,. on page XX), and Supporting Elements (Section B.11, .Supporting Elements,. on page XXX)." e) For Section B.3: add the following paragraph after the table: "These attributes are used for Flow Objects (Section B.4, .Common Flow Object Attributes,. on page XXX), Connecting Objects (Section B.10, .Graphical Connecting Objects,. on page XXX), Swimlanes (Section B.8, .Swimlanes (Pools and Lanes),. on page XXX), Artifacts (Section B.9, .Artifacts,. on page XXX), and Supporting Elements (Section B.11, .Supporting Elements,. on page XXX)." Section 9.2 "Common Flow Object Attributes," page 33 and Section B.4 "Common Flow Object Attributes," page 244 and Section 9.6.1 "Common Swimlane Attributes," page 87 and Section B.8.1 "Common Swimlane Attributes," page 262 and Section 9.7.1 "Common Artifact Attributes," page 92 and Section B.9.1 "Common Artifact Attributes," page 264 and Section 10.1.1 "Common Connecting Object Attributes," page 99 and Section B.10.1 "Common Connecting Object Attributes," page 265: f) At the end of the first sentence of the section, change: "common graphical object attributes" to "common BPMN element attributes" Define the elements that now inherit the common BPMN Element attributes: Section 8.6.1 "Attributes," page 30 and Section B.2 "Process Attributes," page 242 and Section B.11.1 "Assignment," page 268 and Section B.11.2 "Entity," page 268 and Section B.11.3 "Expression," page 269 and Section B.11.4 (new section) "Input," page 269 and Section B.11.5 (was B.11.4) "Message," page 269 and Section B.11.7 (new section) "Output," page 269 and Section B.11.8 (was B.11.6) "Participant," page 270 and Section B.11.9 (was B.11.7) "Property," page 270 and Section B.11.10 (was B.11.8) "Role," page 270 and Section B.11.11 (was B.11.9) "Rule," page 271 and Section B.11.13 (was B.11.10) "Transaction," page 271 and Section B.11.14 (was B.11.11) "Web Service ," page 271: g) Append the end of the first sentence of the section with: ", and which extends the set of common BPMN element attributes (see Table B.2)" Since Processes now inherit BPMN Element attributes, three attributes can be removed: Section 8.6 "Processes," Table 8.7, page 30 and Section B.2 "Process Attributes," Table B.2, page 242: h) Remove the first row of the Table ("Id") i) Remove the last two rows of the Table ("Categories" and "Documentation") Clean up the order of things: j) Switch the order of Sections B.2 and B.3 Other changes: Annex B, prior to Section B.1, after the first paragraph: k) Add the following sentence after the section title:"The following figure displays a diagram of the relationship between the main BPMN Event elements and their attributes (see Figure B.1). Other diagrams in this Annex will provide more detailed information about specific groups of elements (e.g, Events and their related elements and attributes)." l) Add the following figure after the above sentence: m) Add the following figure title after the figure: "Figure B.1 - Main BPMN Elements and Attributes" Set up the restructuring of Events so that Triggers and Results are defined as an EventDetail, which is a Supporting Element: Change Triggers and Results to be of type EventDetail: Section 9.3.2 "Start," Table 9.5, page 38 and Section B.5.2, Table B.6, page 245: n) Remove all the rows except the first row (they will be placed somewhere else) o) Replace the first row with the following: Trigger (0-n) : EventDetail Trigger (EventDetail) is an attribute that defines the type of trigger expected for a Start Event. Of the set of EventDetailTypes (see Section 9.3.5, .Event Details,. on page XX), only four (4) can be applied to a Start Event: Message, Timer, Rule, and Link (see Table 9.4). If there is no EventDetail is defined, then this is considered a None End Event and the Event will not have an internal marker (see Table 9.4). If there is more than one EventDetail is defined, this is considered a Multiple End Event and the Event will have the star internal marker (see Table 9.4). Section 9.3.3 "End," Table 9.7, page 42 and Section B.5.3, Table B.7, page 246: p) Remove all the rows except the first row (they will be placed somewhere else) q) Replace the first row with the following: Result (0-n) : EventDetail Result (EventDetail) is an attribute that defines the type of result expected for an End Event. Of the set of EventDetailTypes (see Section 9.3.5, .Event Details,. on page XX), only six (6) can be applied to an End Event: Message, Error, Cancel, Compensation, Link, and Terminate (see Table 9.6). If there is no EventDetail is defined, then this is considered a None End Event and the Event will not have an internal marker (see Table 9.6). If there is more than one EventDetail is defined, this is considered a Multiple End Event and the Event will have the star internal marker (see Table 9.6). Section 9.3.4 "Intermediate," Table 9.9, page 46 and Section B.5.3, Table B.8, page 247: r) Remove all the rows except the first two rows (they will be placed somewhere else) s) Second row, first column: replace "Object" with "Activity" t) Replace the first row with the following: Trigger (0-n) : EventDetail Trigger (EventDetail) is an attribute that defines the type of trigger expected for an Intermediate Event. Of the set of EventDetailTypes (see Section 9.3.5, .Event Details,. on page XX), only seven (7) can be applied to an Intermediate Event: Message, Timer, Error, Cancel, Compensation, Rule, and Link. (see Table 9.8). If there is no EventDetail is defined, then this is considered a None Intermediate Event and the Event will not have an internal marker (see Table 9.8). If there is more than one EventDetail is defined, this is considered a Multiple Intermediate Event and the Event will have the star internal marker (see Table 9.8). Set up a new Event Details section in Section 9.3 Section 9.3, after sub-section 9.3.4: u) Add new Header level 3 Section (9.3.5) with the following title: "Event Details" v) Add a paragraph after the section title: "Event Details refers to the Triggers of Start and Intermediate Events and the Results of End Events. The types of Event Details are: Message, Timer, Error, Cancel, Compensation, Rule, Link, and Terminate. A None Event is determined by an Event that does not specify an Event Detail. A Multiple Event is determined by an Event that specifies more than one Event Detail. The different types of Events, (Start, Intermediate, and End) utilize a subset of the available types of Event Details (see Figure 9.5)." w) add a figure after the above paragraph: x) add a figure caption for the above figure: "Event Details as Applied to Start, Intermediate, and End Events" y) add a paragraph below the above figure caption: "The following sections will present the attributes common to all Event Details and the specific attributes for the Event Details that have additional attributes. Note that the Cancel and Terminate Event Details do not have additional attributes." z) add new subsection: "Common Event Detail Attributes" aa) add new paragaph in section: "The following table displays the set of attributes common to the types of EventDetail, and which extends the set of common BPMN element attributes (see Table 9.1)." bb) add a table caption for the table below: "Common Event Detail Attributes" cc) Add the following table: Attributes Description EventDetailType (Message | Timer | Error | Rule | Link | Compensate | Cancel | Terminate) Message : String The EventDetailType attribute defines the type of trigger expected for an Event. The set of types includes Message, Timer, Error, Rule, Link, Compensate, Cancel, and Terminate. The EventTypes (Start, Intermediate, and End) will each have a subset of the EventDetailTypes that can be used. The EventDetailType list MAY be extended to include new types. These new types MAY have a new modeler- or tool-defined Marker to fit within the boundaries of the Event. dd) add new subsection: "Compensation Event Detail" ee) add new paragaph in section: "The following table displays the set of attributes a Compensation Event Detail, and which extends the set of common Event Detail attributes (see Table 9.10)." ff) add a table caption for the table below: "Compensation Event Detail Attributes" gg) Add the following table: Attributes Description ActivityRef : Activity For an End Event: If the Result is a Compensation, then the Activity that needs to be compensated MUST be supplied. For an Intermediate Event within Normal Flow: If the Trigger is a Compensation, then the Activity that needs to be compensated MUST be supplied. This .throws. the compensation. For an Intermediate Event attached to the boundary of an Activity: This Event .catches. the compensation. No further information is required. The Activity the Event is attached to will provide the Id necessary to match the compensation event with the event that .threw. the compensation. hh) add new subsection: "Error Event Detail" ii) add new paragaph in section: "The following table displays the set of attributes a Error Event Detail, and which extends the set of common Event Detail attributes (see Table 9.10)." kk) add a table caption for the table below: "Error Event Detail Attributes" ll) Add the following table: Attributes Description ErrorCode : String For an End Event: If the Result is an Error, then the ErrorCode MUST be supplied.This .throws. the error. For an Intermediate Event within Normal Flow: If the Trigger is an Error, then the ErrorCode MUST be entered. This .throws. the error. For an Intermediate Event attached to the boundary of an Activity: If the Trigger is an Error, then the ErrorCode MAY be entered. This Event .catches. the error. If there is no ErrorCode, then any error SHALL trigger the Event. If there is an ErrorCode, then only an error that matches the ErrorCode SHALL trigger the Event. mm) add new subsection: "Link Event Detail" nn) add new paragaph in section: "The following table displays the set of attributes a Link Event Detail, and which extends the set of common Event Detail attributes (see Table 9.10)." oo) add a table caption for the table below: "Link Event Detail Attributes" pp) Add the following table: Attributes Description LinkId : String If the Trigger is a Link, then the LinkId MUST be entered. ProcessRef : Process If the Trigger is a Link, then the ProcessRef MUST be entered. The identified Process MAY be the same Process as that of the Link Event. qq) add new subsection: "Message Event Detail" rr) add new paragaph in section: "The following table displays the set of attributes a Message Event Detail, and which extends the set of common Event Detail attributes (see Table 9.10)." ss) add a table caption for the table below: "Message Event Detail Attributes" tt) Add the following table: Attributes Description MessageRef : Message If the EventDetailType is a MessageRef, then the a Message MUST be supplied. The attributes of a Message can be found in Section B.11.8, .Message,. on page XXX. Implementation (Web Service | Other | Unspecified) Web Service This attribute specifies the technology that will be used to send or receive the message. A Web service is the default technology. uu) add new subsection: "Rule Event Detail" vv) add new paragaph in section: "The following table displays the set of attributes a Rule Event Detail, and which extends the set of common Event Detail attributes (see Table 9.10)." ww) add a table caption for the table below: "Rule Event Detail Attributes" xx) Add the following table: Attributes Description RuleName : Rule If the Trigger is a Rule, then a Rule MUST be entered. The attributes of a Rule can be found in Section B.11.14, .Rule,. on page XXX. yy) add new subsection: "Timer Event Detail" zz) add new paragaph in section: "The following table displays the set of attributes a Timer Event Detail, and which extends the set of common Event Detail attributes (see Table 9.10)." aaa) add a table caption for the table below: "Timer Event Detail Attributes" bbb) Add the following table: Attributes Description TimeDate (0-1) : TimeDateExpression If the Trigger is a Timer, then a TimeDate MAY be entered. If a TimeDate is not entered, then a TimeCycle MUST be entered (see the attribute below). The attributes of a TimeDateExpression can be found in Section B.11.15, .TimeDateExpression,. on page XXX. TimeCycle (0-1) : TimeDateExpression If the Trigger is a Timer, then a TimeCycle MAY be entered. If a TimeCycle is not entered, then a TimeDate MUST be entered (see the attribute above). Set up the Event Details section in Annex B, which is basically the same as in Section 9: Section B.11, after sub-section B.11.2: ccc) Add new Header level 3 Section (B.11.3) with the following title: "Event Details" ddd) add a paragraph in the section: "The following sections will present the attributes common to all Event Details and the specific attributes for the Event Details that have additional attributes. Note that the Cancel and Terminate Event Details do not have additional attributes." fff) add all the Event Detail Sections as defined above, except define references to tables within Annex B Other Changes: Section B.5 "Events": ggg) Add the following sentence after the section title:"The following figure displays a diagram of the relationship between BPMN Event elements and their attributes (see Figure B.X)." hhh) Add the following figure after the above sentence: iii) Add the following figure title after the figure: "Figure B.X - BPMN Event Elements and Attributes" Set up the restructuring of Gateways so that Gates are now a Supporting Element: The Common Gateway attributes should also include the Gates attribute, so Section 9.5.1 "Common Gateway Features," page 70, Table 9.25 and Section B.7.1 "Common Gateway Attributes," page 257, Table B.24 jjj) Add the following row at the end of the table: Gates (0-n) : Gate There MAY be zero or more Gates (except where noted below). Zero Gates are allowed if the Gateway is last object in a Process flow and there are no Start or End Events for the Process. If there are zero or only one incoming Sequence Flow, then there MUST be at least two Gates. For Exclusive Data-Based Gateways When two Gates are required, one of them MAY be the DefaultGate. For Exclusive Event-Based Gateways There MUST be two or more Gates. (Note that this type of Gateway does not act only as a Merge--it is always a Decision, at least.) For Inclusive Gateways When two Gates are required, one of them MAY be the DefaultGate. Section B.7.2 "Exclusive Gateways," page 258, Table B.25 and Section 9.5.2, page 74, Table 9.26: kkk) Remove rows 3 through 5 ("Gates," "Outgoing Sequence Flow," and "Assignments") lll) Remove the last two rows ("Outgoing Sequence Flow," and "Assignments") mmm) Second column in remaining third row: append sentence with: "(see Section B.11.6, .Gate,. on page XXX [Section "Gates" on page XX])" Section B.7.2 "Exclusive Gateways," page 259, Table B.26 and Section 9.5.2, page 77, Table 9.27: nnn) Remove the last three rows ("Gates," "Outgoing Sequence Flow," and "Assignments") Section B.7.3 "Inclusive Gateways," page 260, Table B.27 and Section 9.5.3, page 81, Table 9.28: ooo) Remove the first three rows ("Gates," "Outgoing Sequence Flow," and "Assignments") ppp) Remove the last two rows ("Outgoing Sequence Flow," and "Assignments") qqq) Second column in remaining row: append sentence with: "(see Section B.11.6, .Gate,. on page XXX [Section "Gates" on page XX])" Section B.7.4 "Complex Gateways," page 261, Table B.28 and Section 9.5.4, page 81, Table 9.29: rrr) Remove the first three rows ("Gates," "Outgoing Sequence Flow," and "Assignments") Section B.7.5 "Parallel Gateways," page 260, Table B.29 and Section 9.5.5, page 86, Table 9.30: sss) Remove entire Table (there are no additional attributes) ttt) Replace paragraph in section with: "Parallel Gateways do not have any additional Attributes beyond the common Gateway Attributes (see Table B.24 [Table 9.31]). Section 9.5.1 "Common Gateway Features," page 70, after the "Message Flow Connections" subsection uuu) add new subsection: "Gates" vvv) add new paragaph in section: "The following table displays the attributes of Gates, and which extends the set of common BPMN element attributes (see Table 9.1)" www) add a table caption for the table below: "Gate Attributes" yyy) Add the following table: Attributes Description OutgoingSequenceFlow : SequenceFlow Each Gate MUST have an associated Sequence Flow. The attributes of a Sequence Flow can be found in the Section 10.1.2, .Sequence Flow,. on page XXX. For Exclusive Event-Based, Complex, and Parallel Gateways: The Sequence Flow MUST have its Condition attribute set to None (there is not an evaluation of a condition expression). For Exclusive Data-Based, and Inclusive Gateways: The Sequence Flow MUST have its Condition attribute set to Expression and MUST have a valid ConditionExpression. The ConditionExpression MUST be unique for all the Gates within the Gateway. If there is only one Gate (i.e., the Gateway is acting only as a Merge), then Sequence Flow MUST have its Condition set to None. For DefaultGates: The Sequence Flow MUST have its Condition attribute set to Otherwise Assigments (0-n) : Assignment One or more assignment expressions MAY be made for each Gate. The Assignment SHALL be performed when the Gate is selected. The details of Assignment are defined in the Section B.11.1, .Assignment,. on page XXX. Section B.11 "Supporting Elements," page 269, after the B.11.3 "Expression" section zzz) Add new section: "Gate" aaaa) Add the same paragraph, Table caption, and Table as shown above (adjust the references to Annex B) Other Changes: Section B.7 "Gateways": bbbb) Add the following sentence after the section title:"The following figure displays a diagram of the relationship between BPMN Gateway elements and their attributes (see Figure B.X)." cccc) Add the following figure after the above sentence: dddd) Add the following figure title after the figure: "Figure B.X - BPMN Gateway Elements and Attributes" Add Model Diagrams to sections of Annex B: Section B.6 "Activities": eeee) Add the following sentence after the section title:"The following figure displays a diagram of the relationship between BPMN activity elements and their attributes (see Figure B.X)." ffff) Add the following figure after the above sentence: gggg) Add the following figure title after the figure: "Figure B.X - BPMN Activity Elements and Attributes" Section B.8 "Swimlanes": hhhh) Add the following sentence after the section title:"The following figure displays a diagram of the relationship between BPMN Swimlane elements and their attributes (see Figure B.X)." iiii) Add the following figure after the above sentence: jjjj) Add the following figure title after the figure: "Figure B.X - BPMN Swimlane Elements and Attributes" Section B.9 "Artifacts": kkkk) Add the following sentence after the section title:"The following figure displays a diagram of the relationship between BPMN Artifacts elements and their attributes (see Figure B.X)." llll) Add the following figure after the above sentence: mmmm) Add the following figure title after the figure: "Figure B.X - BPMN Artifact Elements and Attributes" Section B.10 "Connecting Objects": nnnn) Add the following sentence after the section title:"The following figure displays a diagram of the relationship between BPMN Connecting Objects elements and their attributes (see Figure B.X)." oooo) Add the following figure after the above sentence: pppp) Add the following figure title after the figure: "Figure B.X - BPMN Connecting Objects Elements and Attributes" Section B.11"Supporting Types": qqqq) Change the section title to:"Supporting Elements" rrrr) Add the following sentence after the section title:"The following figure displays a diagram of the relationship between BPMN Supporting elements and their attributes (see Figure B.X)." ssss) Add the following figure after the above sentence: tttt) Add the following figure title after the figure: "Figure B.X - BPMN Supporting Elements and Attributes" Yes No Abstain 9410 Make the merging behavior of the Exclusive Gateway exclusive Description: Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family. Resolution: Defer: This issue will be resolved during the next BPMN FTF. Revised Text: None Yes No Abstain