Issue 9326: Unclear semantics of Group (bpmn-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com) Nature: Uncategorized Issue Severity: Summary: Table 8.1: unclear if a Group groups Activities or objects in general. Can it have a name? Resolution: Revised Text: Actions taken: January 30, 2006: received issue April 19, 2007: closed issue Discussion: Resolution: The concepts of Categories and Groups will be aligned. Issue 9324 will specify the required changes to the specification, so no further changes are required for this issue. Revised Text: None End of Annotations:===== ubject: Further BPMN issues Date: Sun, 29 Jan 2006 21:34:26 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Further BPMN issues Thread-Index: AcYlXtWDZBGQwojvTguClGAOoc5ROQ== From: "Pete Rivett" To: , Issue B) Unclear semantics of Group Table 8.1: unclear if a Group groups Activities or objects in general. Can it have a name? To: bpmn-ftf@omg.org Subject: About Groups X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Stephen A White Date: Thu, 16 Mar 2006 18:03:11 -0800 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.53HF743 | November 3, 2005) at 03/16/2006 19:03:14, Serialize complete at 03/16/2006 19:03:14 The entire set of Group attributes is: id: Object -- [from GraphicalObject] category(0..n): string -- [from GraphicalObject] documentation(0..1): string -- [from GraphicalObject] artifactTypes: Types = "Group" -- [from Artifact] pool: Pool -- [from Artifacts] lane(0..1): Lane -- [from Artifacts] name: string A couple of questions: A Group gets the pool and lane attributes from the set of common Artifact attributes. But a Group is not constrained to a single Pool. What should be done about this? Should we add the property attribute to a Group to allow more detailed reporting (beyond category and description)? -Steve Subject: RE: About Groups Date: Fri, 17 Mar 2006 09:51:34 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About Groups Thread-Index: AcZJZo8IwJRwlJuPRBGiUfRhtGqwsgAexj8A From: "Michelle Vanchu-Orosco" To: "Stephen A White" , X-OriginalArrivalTime: 17 Mar 2006 16:51:37.0611 (UTC) FILETIME=[0E7CEDB0:01C649E3] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.52.1006-14329.000 X-TM-AS-Result: No--3.100000-8.000000-31 Also, are the objects in the group parented to the group? Based on the meeting notes (and my recollections of the conversation) In the discussion we realized that the definition of the Group does not provide the information necessary to know what elements actually reside in the Group. Thus, we decided that we need to add an attribute (GraphicalElement (0..n)) to the definition of a Group. So. what would happen to the elements in the group if the user decided to move the group? Do they reside in the Pool and the Group? Michelle -------------------------------------------------------------------------------- From: Stephen A White [mailto:wstephe@us.ibm.com] Sent: Thursday, March 16, 2006 7:03 PM To: bpmn-ftf@omg.org Subject: About Groups The entire set of Group attributes is: id: Object -- [from GraphicalObject] category(0..n): string -- [from GraphicalObject] documentation(0..1): string -- [from GraphicalObject] artifactTypes: Types = "Group" -- [from Artifact] pool: Pool -- [from Artifacts] lane(0..1): Lane -- [from Artifacts] name: string A couple of questions: A Group gets the pool and lane attributes from the set of common Artifact attributes. But a Group is not constrained to a single Pool. What should be done about this? Should we add the property attribute to a Group to allow more detailed reporting (beyond category and description)? -Steve group.JPG Subject: RE: About Groups Date: Fri, 17 Mar 2006 11:56:37 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: About Groups Thread-Index: AcZJZo8IwJRwlJuPRBGiUfRhtGqwsgAexj8AAABq4lA= From: "Rob Bartel" To: "Stephen A White" , I don't believe this kind of tool/UI behavior is in scope for this standard. I consider is entirely reasonable for one tool to choose to move the objects, and another one not to. In the end, the reader of the diagram (this is a notation spec, afterall) can't tell the difference, nor are there process-behavioral differences. Therefore, I'd argue it should remain unspecified. Rob -------------------------------------------------------------------------------- From: Michelle Vanchu-Orosco [mailto:Michelle.Vanchu-Orosco@EMBARCADERO.COM] Sent: Friday, March 17, 2006 8:52 AM To: Stephen A White; bpmn-ftf@omg.org Subject: RE: About Groups Also, are the objects in the group parented to the group? Based on the meeting notes (and my recollections of the conversation) In the discussion we realized that the definition of the Group does not provide the information necessary to know what elements actually reside in the Group. Thus, we decided that we need to add an attribute (GraphicalElement (0..n)) to the definition of a Group. So. what would happen to the elements in the group if the user decided to move the group? Do they reside in the Pool and the Group? Michelle -------------------------------------------------------------------------------- From: Stephen A White [mailto:wstephe@us.ibm.com] Sent: Thursday, March 16, 2006 7:03 PM To: bpmn-ftf@omg.org Subject: About Groups The entire set of Group attributes is: id: Object -- [from GraphicalObject] category(0..n): string -- [from GraphicalObject] documentation(0..1): string -- [from GraphicalObject] artifactTypes: Types = "Group" -- [from Artifact] pool: Pool -- [from Artifacts] lane(0..1): Lane -- [from Artifacts] name: string A couple of questions: A Group gets the pool and lane attributes from the set of common Artifact attributes. But a Group is not constrained to a single Pool. What should be done about this? Should we add the property attribute to a Group to allow more detailed reporting (beyond category and description)? -Steve -- This message has been scanned for viruses and dangerous content and is believed to be clean. Date: Fri, 17 Mar 2006 17:28:22 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: bpmn-ftf@omg.org Subject: Re: BPMN Issue 9326 About Groups Steve wrote: The entire set of Group attributes is: id: Object -- [from GraphicalObject] category(0..n): string -- [from GraphicalObject] documentation(0..1): string -- [from GraphicalObject] artifactTypes: Types = "Group" -- [from Artifact] pool: Pool -- [from Artifacts] lane(0..1): Lane -- [from Artifacts] name: string A couple of questions: 1. A Group gets the pool and lane attributes from the set of common Artifact attributes. But a Group is not constrained to a single Pool. What should be done about this? I think we all agree that it was not the intent of the spec to require that a Group be limited to a single Lane or even a single Pool. But what that means is that neither the Pool nor the Lane is required to be the parent of the Group. So the interpretation of lane: [0..1] Lane is that a Group may have a Lane as its parent, or may be independent of Lanes. Now if a Group has a Lane as its parent, can it extend to elements outside the Lane? (I would think No.) The relationship to Pool should then be the same, viz.: pool: [0..1] Pool and have a similar interpretation. A Group that spans Lanes may still have a parent Pool. But a Group that spans Pools has only the Model for a parent. I don't think it will hurt BPMN to generalize the "pool" attribute of Artifact to pool: [0..1] Pool. And then Group can inherit that attribute and provide its specialized interpretation, as above. I think the parent Pool is probably optional for some other Artifacts as well. If some specific Artifact really requires a parent Pool, that is a constraint on the specific subtype of Artifact, and we can state that constraint where needed. 2. Should we add the property attribute to a Group to allow more detailed reporting (beyond category and description)? IMO, "It couldn't hurt." If people want to attach special semantics to a Group, this gives them a way. But I'll accept whatever resolution of this (sub)issue is proposed by the implementors. Michelle wrote: Also, are the objects in the group parented to the group? NO. If we said they were, we would have to define the semantics of the parentage, and therefore the grouping. Further, I think that would mess up the existing well-defined parentage of the graphical elements, like Activities belonging to Lanes or Pools. Based on the meeting notes (and my recollections of the conversation) In the discussion we realized that the definition of the Group does not provide the information necessary to know what elements actually reside in the Group. Thus, we decided that we need to add an attribute (GraphicalElement (0..n)) to the definition of a Group. Yes. That means a tool can't just treat a group as a hollow box on the diagram. It is a conceptual object that has a content. The intent is that the Group semantics is *added to* the intrinsic semantics of the graphical elements and their placement in lanes, pools, etc. So... what would happen to the elements in the group if the user decided to move the group? Do they reside in the Pool and the Group? Rob answered: I don't believe this kind of tool/UI behavior is in scope for this standard. I consider is entirely reasonable for one tool to choose to move the objects, and another one not to. In the end, the reader of the diagram (this is a notation spec, afterall) can't tell the difference, nor are there process-behavioral differences. Therefore, I'd argue it should remain unspecified. I agree with this. -Ed P.S. I changed the subject line so that it is clear to all that we are discussing the fallout from Pete's Issue 9326. We might need to create a separate Issue for the change to Artifact, if the FTF agrees on that approach. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: RE: BPMN Issue 9326 About Groups Date: Fri, 17 Mar 2006 17:42:18 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BPMN Issue 9326 About Groups Thread-Index: AcZKEj0bMSnUBU5JSlCp4HJ/HNrRtAAADTjw From: "Rob Bartel" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k2HMXRtt003978 Ed I believe that the BPD is the parent of all Groups, and that lanes and pools are overlapped by the Group. I'll note that we don't appear to have a Parent-like attribute on Graphical objects at all, do we? There's some loose reference to Parent process for embedded subprocess, and explict ParentLane and ParentPool attributes for Lane, but otherwise I don't believe the spec deals much with parentage at all. Also, it's not clear whether the word as you used it here means "existence parent" or just a higher level scope. In any event, I think we should just make both the Pool and Lane attributes of Group a [0..n]. -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Friday, March 17, 2006 2:28 PM To: bpmn-ftf@omg.org Subject: Re: BPMN Issue 9326 About Groups Steve wrote: > The entire set of Group attributes is: > > id: Object -- [from GraphicalObject] > category(0..n): string -- [from GraphicalObject] > documentation(0..1): string -- [from GraphicalObject] > artifactTypes: Types = "Group" -- [from Artifact] > pool: Pool -- [from Artifacts] > lane(0..1): Lane -- [from Artifacts] > name: string > > A couple of questions: > > 1. A Group gets the pool and lane attributes from the set of common > Artifact attributes. But a Group is not constrained to a single Pool. > What should be done about this? I think we all agree that it was not the intent of the spec to require that a Group be limited to a single Lane or even a single Pool. But what that means is that neither the Pool nor the Lane is required to be the parent of the Group. So the interpretation of lane: [0..1] Lane is that a Group may have a Lane as its parent, or may be independent of Lanes. Now if a Group has a Lane as its parent, can it extend to elements outside the Lane? (I would think No.) The relationship to Pool should then be the same, viz.: pool: [0..1] Pool and have a similar interpretation. A Group that spans Lanes may still have a parent Pool. But a Group that spans Pools has only the Model for a parent. I don't think it will hurt BPMN to generalize the "pool" attribute of Artifact to pool: [0..1] Pool. And then Group can inherit that attribute and provide its specialized interpretation, as above. I think the parent Pool is probably optional for some other Artifacts as well. If some specific Artifact really requires a parent Pool, that is a constraint on the specific subtype of Artifact, and we can state that constraint where needed. > 2. Should we add the property attribute to a Group to allow more > detailed reporting (beyond category and description)? IMO, "It couldn't hurt." If people want to attach special semantics to a Group, this gives them a way. But I'll accept whatever resolution of this (sub)issue is proposed by the implementors. Michelle wrote: > Also, are the objects in the group parented to the group? NO. If we said they were, we would have to define the semantics of the parentage, and therefore the grouping. Further, I think that would mess up the existing well-defined parentage of the graphical elements, like Activities belonging to Lanes or Pools. > Based on the meeting notes (and my recollections of the conversation) > > In the discussion we realized that the definition of the Group does > not provide the information necessary to know what elements actually > reside in the Group. Thus, we decided that we need to add an attribute > (GraphicalElement (0..n)) to the definition of a Group. Yes. That means a tool can't just treat a group as a hollow box on the diagram. It is a conceptual object that has a content. The intent is that the Group semantics is *added to* the intrinsic semantics of the graphical elements and their placement in lanes, pools, etc. > So... what would happen to the elements in the group if the user > decided to move the group? Do they reside in the Pool and the Group? Rob answered: > I don't believe this kind of tool/UI behavior is in scope for this > standard. I consider is entirely reasonable for one tool to choose to > move the objects, and another one not to. In the end, the reader of > the diagram (this is a notation spec, afterall) can't tell the > difference, nor are there process-behavioral differences. Therefore, > I'd argue it should remain unspecified. I agree with this. -Ed P.S. I changed the subject line so that it is clear to all that we are discussing the fallout from Pete's Issue 9326. We might need to create a separate Issue for the change to Artifact, if the FTF agrees on that approach. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- This message has been scanned for viruses and dangerous content, and is To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9326 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Sat, 21 Oct 2006 17:21:36 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/21/2006 18:21:37, Serialize complete at 10/21/2006 18:21:37 This intended for Ballot 4 http://www.bpmn.org/FTF/Issues/Issue%209326.htm Issue 9326: Unclear semantics for Group Description: Table 8.1: unclear if a Group groups Activities or objects in general. Can it have a name? Discussion Thread in E-Mail Archive: Suggested 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 Subject: RE: Proposed Resolution for Issue 9326 Date: Mon, 23 Oct 2006 06:35:55 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution for Issue 9326 Thread-Index: Acb1cB81B+NVYWemQ8K1DifGvePkbQBNkQqQ From: "Karl Frank" To: "Stephen A White" , X-OriginalArrivalTime: 23 Oct 2006 13:35:57.0540 (UTC) FILETIME=[2BBD4240:01C6F6A8] X-TM-AS-Product-Ver: SMEX-7.0.0.1499-3.6.1039-14768.002 X-TM-AS-Result: No--13.700400-8.000000-31 IMO, this does not resolve 9326 because it gives 9324 more credit than it deserves.Groups and Categories are not specified as equivalent concepts, and 9326 assumes they are. Tho the word used is "combined": 1. 9324 suggests, but does not explicitly state, that Groups can contain any Graphic element, but shall NOT contain any non-graphic element. This leaves the question open what a Group can group, because what is available as a graphic on the screen for "highlighting" or box-enclosure is not well defined, and is certain to be implementation specific. 2. 9324 relates Groups and Categories, but retains a conceptual distinction between Categories and Groups , so it is misleading to say it "combines" them. The "Suggested Resolution" dismisses the issue on the assumption that the semantics of Category is clear, and Group now is equivalent to Category, but they are not equivalent, since Groups are graphic and Categories need not be. - Karl -------------------------------------------------------------------------------- From: Stephen A White [mailto:wstephe@us.ibm.com] Sent: Saturday, October 21, 2006 8:22 PM To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9326 This intended for Ballot 4 http://www.bpmn.org/FTF/Issues/Issue%209326.htm Issue 9326: Unclear semantics for Group Description: Table 8.1: unclear if a Group groups Activities or objects in general. Can it have a name? Discussion Thread in E-Mail Archive: Suggested 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 Subject: RE: Proposed Resolution for Issue 9326 To: "Karl Frank" Cc: bpmn-ftf@omg.org, "Stephen A White" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Suzette Samoojh Date: Mon, 23 Oct 2006 11:27:34 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 6.5.4|March 27, 2005) at 10/23/2006 11:27:35 Karl, "Karl Frank" wrote on 10/23/2006 09:35:55 AM: > IMO, this does not resolve 9326 because it gives 9324 more credit > than it deserves.Groups and Categories are not specified as > equivalent concepts, and 9326 assumes they are. Tho the word used > is "combined": I agree that "combined" is inappropriate. A more correct phrase would be "aligned". > 1. 9324 suggests, but does not explicitly state, that Groups can > contain any Graphic element, but shall NOT contain any non-graphic > element. This leaves the question open what a Group can group, > because what is available as a graphic on the screen for > "highlighting" or box-enclosure is not well defined, and is certain > to be implementation specific. As I understand it, all graphics on the screen are GraphicalObjects. A vendor wishing to add new graphics would provide an Artifact extension, which would then be a GraphicalObject. So I'm not sure I understand why the following change (documented in the resolution for 9324) would be insufficient: |-------------+----------------------------------------------------------| | 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. | |-------------+----------------------------------------------------------| > 2. 9324 relates Groups and Categories, but retains a conceptual > distinction between Categories and Groups , so it is misleading to > say it "combines" them. The "Suggested Resolution" dismisses the > issue on the assumption that the semantics of Category is clear, and > Group now is equivalent to Category, but they are not equivalent, > since Groups are graphic and Categories need not be. > > - Karl > > From: Stephen A White [mailto:wstephe@us.ibm.com] > Sent: Saturday, October 21, 2006 8:22 PM > To: bpmn-ftf@omg.org > Subject: Proposed Resolution for Issue 9326 > > This intended for Ballot 4 > > http://www.bpmn.org/FTF/Issues/Issue%209326.htm > > Issue 9326: Unclear semantics for Group > Description: > > Table 8.1: unclear if a Group groups Activities or objects in > general. Can it have a name? > > Discussion Thread in E-Mail Archive: > > Suggested 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 Suzette To: Suzette Samoojh , bpmn-ftf@omg.org, "Karl Frank" Subject: RE: Proposed Resolution for Issue 9326 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Mon, 23 Oct 2006 13:57:41 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/23/2006 14:57:43, Serialize complete at 10/23/2006 14:57:43 The description of the resolution will be changed from "combined" to "aligned." They are not truly combined since Group is a graphical element and Category is a supporting element. As mentioned in the other thread, the GraphicalElements type will be changed from Object to Graphical Element. I believe the spec now specifies that graphical elements are affected by the Group (that is, grouped). I'm not sure how much should be said about non-graphical elements, since the modeler isn't grouping them in the model. I'll be sending out a new draft of the ballot for people to look at today. Beyond that, is there any text revisions that Issue 9326 should propose beyond what is in Issue 9324? -Steve Suzette Samoojh 10/23/2006 08:27 AM To "Karl Frank" cc bpmn-ftf@omg.org, Stephen A White/Irvine/IBM@IBMUS Subject RE: Proposed Resolution for Issue 9326 Karl, "Karl Frank" wrote on 10/23/2006 09:35:55 AM: > IMO, this does not resolve 9326 because it gives 9324 more credit > than it deserves.Groups and Categories are not specified as > equivalent concepts, and 9326 assumes they are. Tho the word used > is "combined": I agree that "combined" is inappropriate. A more correct phrase would be "aligned". > 1. 9324 suggests, but does not explicitly state, that Groups can > contain any Graphic element, but shall NOT contain any non-graphic > element. This leaves the question open what a Group can group, > because what is available as a graphic on the screen for > "highlighting" or box-enclosure is not well defined, and is certain > to be implementation specific. As I understand it, all graphics on the screen are GraphicalObjects. A vendor wishing to add new graphics would provide an Artifact extension, which would then be a GraphicalObject. So I'm not sure I understand why the following change (documented in the resolution for 9324) would be insufficient: |-------------+-----------------------------------------------------------| | 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. | |-------------+-----------------------------------------------------------| > 2. 9324 relates Groups and Categories, but retains a conceptual > distinction between Categories and Groups , so it is misleading to > say it "combines" them. The "Suggested Resolution" dismisses the > issue on the assumption that the semantics of Category is clear, and > Group now is equivalent to Category, but they are not equivalent, > since Groups are graphic and Categories need not be. > > - Karl > > From: Stephen A White [mailto:wstephe@us.ibm.com] > Sent: Saturday, October 21, 2006 8:22 PM > To: bpmn-ftf@omg.org > Subject: Proposed Resolution for Issue 9326 > > This intended for Ballot 4 > > http://www.bpmn.org/FTF/Issues/Issue%209326.htm > > Issue 9326: Unclear semantics for Group > Description: > > Table 8.1: unclear if a Group groups Activities or objects in > general. Can it have a name? > > Discussion Thread in E-Mail Archive: > > Suggested 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 Suzette Subject: RE: Draft of Ballot 4, comments on 9319 and 9326 Date: Mon, 23 Oct 2006 13:14:31 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of Ballot 4, comments on 9319 and 9326 Thread-Index: Acb20/pcEYCwHVPaR76HvlvGTp7wqAABNe+w From: "Karl Frank" To: , "Stephen A White" Cc: "BPMN FTF" X-OriginalArrivalTime: 23 Oct 2006 20:14:29.0948 (UTC) FILETIME=[D8A527C0:01C6F6DF] X-TM-AS-Product-Ver: SMEX-7.0.0.1499-3.6.1039-14770.000 X-TM-AS-Result: No--23.346300-8.000000-31 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k9NKBqtF007039 wrt 9326 below see my comments inline at - Karl -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Monday, October 23, 2006 2:49 PM To: Stephen A White Cc: BPMN FTF Subject: Re: Draft of Ballot 4, comments on 9319 and 9326 Stephen A White wrote: > Below is a draft of Ballot 4 > > Please review for format and content, and provide feedback. > 9318 ... > 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." Add (another issue may have added this): This version of the specification does not specify a normative mapping from BPMN to WSBPEL. Note: This version does provide a non-normative mapping from BPMN to WSBPEL, but the BPMN specification itself is known to be incomplete with respect to capturing all the required information for WSBPEL. So the mapping is insufficient, in any case. > 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. > ... At the end, add: In Clause 6.2, a) Renumber and retitle Clause 6.2 to: "6.1.2 Abbreviations" b) Delete the first paragraph of 6.2. [This aligns the proposed ballot text with my fixups.] > 9324 > ... > > 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: Suggest: A Group groups all the objects within the demarked area, including Activities, Flows, Artifacts, Gateways, etc. This does not appear to require any change to the specification. starting point: Nice switch from talk about drawing boxes to this more general notion of demarked area. Can allow for color, etc. as the demarcation feature. But: Membership in a group is hereby restricted to GraphicalObjects, and to instances actually visible on some diagram. This is in line with the origin of the notion, in a box drawn on a diagram. The issue is: Are we clear that membership in a Category is likewise restricted to graphicalObject? If not, when a Group represents a Category, does it also by my implication represent the non-Graphical contents of the Category (although of course these will not be visible in the demarked area. And how do the non-grpahical members ever get into the Category? If spec does have same restriction on membership (to graphicals), the Group and Category concepts become fully equivalent, or more exactly, there is no Group concept, just a group notation, and the concept it represents is Category. If so, we should make do with just one of these. The resolution to Issue 9324 makes Group a representation of Category. A Name, Description, and other Properties can be assigned to the Category and thereby to the corresponding Group, if any. > 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 > > 9328 > ... > > 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 I thought we agreed to a solution to this, but the writeup is essentially to replace every occurrence of an attribute table. So it is deferred waiting for a lot of text. > 9355 > ... > > 9356 > ... > > 9357 > ... > > 9367 This is as far as I got, and I'm still thinking about this one... -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST,