Issue 9139: Section 6 of the current specification should be moved as an appendix (bpmn-ftf) Source: MEGA International (Mr. Antoine Lonjon, antoine.lonjon@mega.com alonjon@mega.com mblin@mega.com) Nature: Uncategorized Issue Severity: Summary: BPMN1. Section 6 of the current specification should be moved as an appendix 2. All attributes related to the BPEL mapping should be removed Resolution: see below Revised Text: a) Rename the title of Annex A from "E-Mail Voting Process BPEL4WS" to "Mapping to BPEL4WS" b) Add a new introductory paragraph with the text: "This annex provides information and examples about how BPMN will map to BPEL4WS 1.1." c) Move Section 11 of the Specification to Appendix A, within the first Heading2 item ("A.1"). All the section, table, and figure headings need to be updated. d) Section A.1, first paragraph: append the paragraph with the following two sentences: "Note that there are known issues with the mapping as specified. Fixes to these issues will be incorporated in a later revision of the specification." e) Copy Section 12 ("BPMN by Example") and paste into the second Heading2 item ("A.2") of Appendix A. All the section, table, figure, and example headings need to be updated. Section 12 will remain, but the mapping sections will be removed. f) Section A.2 (new), first paragraph: Append first sentence with the text "...and will extend Section 11 by adding information about how the example Process will map to BPEL4WS." g) Demote the current title ("E-Mail Voting Process BPEL4WS") to Heading2 and move to the third Heading2 item ("A.3"). h) Remove the current A.1 section title ("Introduction")--but leave the first paragraph of that section (which will now be in A.3) and the table that follows. i) Section 11 (was 12), first paragraph: remove last sentence. j) Section 11 (was 12): remove Section 11.1.1, Section 11.2.1, Section 11.3.1, and Section 11.4.1. k) Section 6.2, page 6, first paragraph: replace "...is a normative part..." with "...is a non-normative part..." l) Section 6.3, page 6: remove fifth paragraph m) Section 6.3, page 6, sixth (now fifth) paragraph: remove the following text from the end of the sentence: " and its particular mapping to BPEL4WS" n) Section 6.3, page 6: replace the seventh (now sixth) paragraph with: "Annex A: Mapping to BPEL4WS provides a mechanism for converting a Business Process to a BPEL4WS document, provides and example of Process mapping, and provides a full sample of BPEL4WS code based on the example process mapping." o) Section 7, page 9, third paragraph. second sentence: replace "...formal mapping..." with "...mapping..." p) Section 8.6.1, page 30, Table 8.7, third row (ProcessType), second column: remove all the sentences after the second sentence. q) Section 8.6.1, page 31, Table 8.7: remove the fourth row (SuppressJoinFailure) and the fifth row (EnableInstanceCompensation) on the page from the table. These rows will remain in a table in Appendix A. r) Section B.2, page 243, Table B.2: remove the third row (SuppressJoinFailure) and the fourth row (EnableInstanceCompensation) on the page from the table. These rows will remain in a table in Appendix A. s) Section 9, page 33, first paragraph: reset the reference to the BPEL mapping section to Appendix A t) Section 9.5.2, Sub-Section "Event-Based," page 75, first paragraph, first sentence: replace the text "...will map to the BPEL4WS pick." to "...was derived from the BPEL4WS pick." u) Section 9.5.2, Sub-Section "Event-Based," page 76: move last paragraph on page to Section A.1.6 (new section as per above changes), Sub-Section "Event- Based," page TBD, after the section title. v) Section 9.6, page 86, first paragraph: remove the first two sentences. w) Section 9.6, page 86, second paragraph: remove the first two sentences. x) Section 9.6, page 86: combine the first two paragraphs into one paragraph. y) Section 9.7.4, page 96, last paragraph on page: remove the following text from the end of the last sentence: " and do not map to any BPEL4WS elements." z) Section 10.2.1, Sub-Section "Joining Flow," page 114: remove last paragraph on page. aa) Section 10.2.1, Sub-Section "Merging Flow," page 121: remove first paragraph on page. bb) Section 10.2.2, page 131, last paragraph on page: remove first sentence. cc) Section 10.2.2, page 132, first paragraph on page (continues from last page): remove sentence. dd) Section 10.2.2, page 132: combine the first two paragraphs. ee) Section B.2, page 242, Table B.2, third row (ProcessType), second column: remove all the sentences after the second sentence. ff) Section B.11.7, page 270, Table B.47, third row (Correlation), second column: remove second paragraph. gg) Section B.11.11, page 271, Table B.51, first row (Participant), second column: remove second sentence. Actions taken: November 3, 2005: received comment July 26, 2006: moved to bpmn-ftf April 19, 2007: closed issue Discussion: Resolution: Section 11 of the Specification will be moved to Annex A. The current contents of Annex A will remain as a section. Other changes will be made to make the specification more readable (in terms of BPEL mapping) following the concerns raised in Issues 9322 and 9323. End of Annotations:===== ubject: AI-5 Date: Wed, 1 Mar 2006 16:20:17 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI-5 Thread-Index: AcY9de/S/st3rsc5TuqV0B+KMlOkgg== From: "Rob Bartel" To: I have been doing some work to resolve AI-5, which is to identify attributes included solely for BPEL4WS. In a preliminary scan of the spec, I only found three for which the text specifically says they were included for BPEL4WS: On the Process object: SuppressJoinFailure EnableInstanceCompensation On the Property object (though the description appears to be incorrect) Correlation However, my history with this spec suggests that many more would not be there were it not necessary to map to BPEL4WS. In some cases entire objects seem to be there largely to support mapping to BPEL4WS. Full disclosure: I am a member of the school of thought that says that BPMN should be a standard for a diagramming methodology, the focus of which is to communicate in a diagram the sequencing, parallelism and synchronization of a business process - including exceptional conditions. In other words, "when does work get done". I do not believe it enhances the standard to specify attributes that have no standardized effect on the diagram displayed and no standardized effect on the time at which things are occur. I also do not understand why execution in BPEL drives so many of the hidden attributes, but other interesting attributes are omitted including resource allocation and simulation modeling data. Before completing this action item, I'd like to understand the sense of the group about what attributes/objects should make the list. Let me pick on two in particular, to give you an idea of what I'm wondering. The Expression object is standardized as a String and a statement that it can be evaluated to produce a result. The only standardized use that is ever made of this object, so far as I am aware, is when emitting BPEL4WS. If we were to remove BPEL4WS from the spec I believe a strong argument could be made that it does not enhance the document as a "standard" to describe an attribute as an uninterpreted string, but still it is a string that is intended to have specific meaning. Since it does not affect the displayed diagram it does not standardize communication between humans. Since it does not have any standard semantics it does not standardize communications between tools. The second target I'll pick on is WebService. This object clearly has the same problems that Expression does, but additionally it is not at all clear that it is a good idea to embed the choice of web service, or indeed any implementation at all, in the process model. It seems to me a vendor and it's toolset should be able to support the standard but provide alternative ways of deployment-time mapping of the work done at an activity to a specific real-world or simulated implementation. The market can determine if that's a better solution or not, but I do not believe sufficient attention or debate has been given to this object and its uses in BPMN to claim that we can *standardize* how it's done. This email is a request for clarification on the question of what AI-5 is intended to accomplish, and I would appreciate responses to that. However, it is also a ill-disguised plea to consider removing a significant number of attributes and objects, particularly those that were added late in the 1.0 specification process with relatively little debate or review to support mapping to BPEL4WS. I would very much prefer to see them moved to a separate paper that describes one technique for mapping a BPMN diagram to a specific execution language. This is an important validation of the standard and proof- of-concept, but I do not believe it should be a part of this specification. Subject: RE: AI-5 Date: Wed, 1 Mar 2006 16:58:00 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI-5 Thread-Index: AcY9eg1o9PdVmGWvTTCc2MaDLlEvmwAAC7Dw From: "Rob Bartel" To: "Juergen Boldt" AI-5 is described at http://www.bpmn.org/FTF/FTF%20Action%20Items.htm and the issues it impacts are 9139, 9240, 9318, 9319, 9322... It's really background work that needed to be done before we could address those, as I understand it (I wasn't there when the AI was created). If you want to associate it with a single issue, I'd use 9139 . (It looks to me like 9240 should be combined with 9319, by the way). -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, March 01, 2006 1:49 PM To: Rob Bartel Subject: RE: AI-5 Thanks Rob, what is the issue number? -Juergen At 04:47 PM 3/1/2006, you wrote: Ooops, maybe I sent this to the wrong address? I meant to send it to the FTF mailing list, but I don't remember it and the bpmn.org site has been down all day and I just used a stored email address that looks right. AI-5 is action item number 5 - this is part of resolving and existing issue, not a new one. Rob -------------------------------------------------------------------------------- From: Juergen Boldt [ mailto:juergen@omg.org] Sent: Wednesday, March 01, 2006 1:23 PM To: Rob Bartel Subject: Re: AI-5 Hi Rob, what is AI-5? I assume log this as an issue? -Juergen At 04:20 PM 3/1/2006, you wrote: I have been doing some work to resolve AI-5, which is to identify attributes included solely for BPEL4WS. In a preliminary scan of the spec, I only found three for which the text specifically says they were included for BPEL4WS: On the Process object: SuppressJoinFailure EnableInstanceCompensation On the Property object (though the description appears to be incorrect) Correlation However, my history with this spec suggests that many more would not be there were it not necessary to map to BPEL4WS. In some cases entire objects seem to be there largely to support mapping to BPEL4WS. Full disclosure: I am a member of the school of thought that says that BPMN should be a standard for a diagramming methodology, the focus of which is to communicate in a diagram the sequencing, parallelism and synchronization of a business process - including exceptional conditions. In other words, "when does work get done". I do not believe it enhances the standard to specify attributes that have no standardized effect on the diagram displayed and no standardized effect on the time at which things are occur. I also do not understand why execution in BPEL drives so many of the hidden attributes, but other interesting attributes are omitted including resource allocation and simulation modeling data. Before completing this action item, I'd like to understand the sense of the group about what attributes/objects should make the list. Let me pick on two in particular, to give you an idea of what I'm wondering. The Expression object is standardized as a String and a statement that it can be evaluated to produce a result. The only standardized use that is ever made of this object, so far as I am aware, is when emitting BPEL4WS. If we were to remove BPEL4WS from the spec I believe a strong argument could be made that it does not enhance the document as a "standard" to describe an attribute as an uninterpreted string, but still it is a string that is intended to have specific meaning. Since it does not affect the displayed diagram it does not standardize communication between humans. Since it does not have any standard semantics it does not standardize communications between tools. The second target I'll pick on is WebService. This object clearly has the same problems that Expression does, but additionally it is not at all clear that it is a good idea to embed the choice of web service, or indeed any implementation at all, in the process model. It seems to me a vendor and it's toolset should be able to support the standard but provide alternative ways of deployment-time mapping of the work done at an activity to a specific real-world or simulated implementation. The market can determine if that's a better solution or not, but I do not believe sufficient attention or debate has been given to this object and its uses in BPMN to claim that we can *standardize* how it's done. This email is a request for clarification on the question of what AI-5 is intended to accomplish, and I would appreciate responses to that. However, it is also a ill-disguised plea to consider removing a significant number of attributes and objects, particularly those that were added late in the 1.0 specification process with relatively little debate or review to support mapping to BPEL4WS. I would very much prefer to see them moved to a separate paper that describes one technique for mapping a BPMN diagram to a specific execution language. This is an important validation of the standard and proof- of-concept, but I do not believe it should be a part of this specification. Juergen Boldt Director, Member Services 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- This message has been scanned for viruses and dangerous content and is believed to be clean. Juergen Boldt Director, Member Services 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- This message has been scanned for viruses and dangerous content and is believed to be clean. Subject: RE: AI-5 Date: Thu, 2 Mar 2006 07:42:42 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI-5 Thread-Index: AcY9de/S/st3rsc5TuqV0B+KMlOkggAiEsXw From: "Cummins, Fred A" To: "Rob Bartel" , X-OriginalArrivalTime: 02 Mar 2006 13:43:13.0759 (UTC) FILETIME=[40ABBEF0:01C63DFF] Rob, My view is that BPMN should be platform independent, and I consider BPEL to be a "platform." As for the two examples: The expression object might be used for expression of conditions that would be platform independent. However, as an "expression" it is implied that it will be in a particular language. This will be resolved in BPDM where there is some discussion regarding the form of conditions--one option is that they are expressed in natural language (for business people). The alternative would be to base it on another language like OCL. We might look at the approach being taken in the Production Rules Representation (PRR) specification. The "WebService" specification certainly sounds like the model would be platform specific, so I would agree that it should not be part of BPMN. Fred -------------------------------------------------------------------------------- From: Rob Bartel [mailto:Rob.Bartel@igrafx.com] Sent: Wednesday, March 01, 2006 4:20 PM To: bpmn-ftf@omg.org Subject: AI-5 I have been doing some work to resolve AI-5, which is to identify attributes included solely for BPEL4WS. In a preliminary scan of the spec, I only found three for which the text specifically says they were included for BPEL4WS: On the Process object: SuppressJoinFailure EnableInstanceCompensation On the Property object (though the description appears to be incorrect) Correlation However, my history with this spec suggests that many more would not be there were it not necessary to map to BPEL4WS. In some cases entire objects seem to be there largely to support mapping to BPEL4WS. Full disclosure: I am a member of the school of thought that says that BPMN should be a standard for a diagramming methodology, the focus of which is to communicate in a diagram the sequencing, parallelism and synchronization of a business process - including exceptional conditions. In other words, "when does work get done". I do not believe it enhances the standard to specify attributes that have no standardized effect on the diagram displayed and no standardized effect on the time at which things are occur. I also do not understand why execution in BPEL drives so many of the hidden attributes, but other interesting attributes are omitted including resource allocation and simulation modeling data. Before completing this action item, I'd like to understand the sense of the group about what attributes/objects should make the list. Let me pick on two in particular, to give you an idea of what I'm wondering. The Expression object is standardized as a String and a statement that it can be evaluated to produce a result. The only standardized use that is ever made of this object, so far as I am aware, is when emitting BPEL4WS. If we were to remove BPEL4WS from the spec I believe a strong argument could be made that it does not enhance the document as a "standard" to describe an attribute as an uninterpreted string, but still it is a string that is intended to have specific meaning. Since it does not affect the displayed diagram it does not standardize communication between humans. Since it does not have any standard semantics it does not standardize communications between tools. The second target I'll pick on is WebService. This object clearly has the same problems that Expression does, but additionally it is not at all clear that it is a good idea to embed the choice of web service, or indeed any implementation at all, in the process model. It seems to me a vendor and it's toolset should be able to support the standard but provide alternative ways of deployment-time mapping of the work done at an activity to a specific real-world or simulated implementation. The market can determine if that's a better solution or not, but I do not believe sufficient attention or debate has been given to this object and its uses in BPMN to claim that we can *standardize* how it's done. This email is a request for clarification on the question of what AI-5 is intended to accomplish, and I would appreciate responses to that. However, it is also a ill-disguised plea to consider removing a significant number of attributes and objects, particularly those that were added late in the 1.0 specification process with relatively little debate or review to support mapping to BPEL4WS. I would very much prefer to see them moved to a separate paper that describes one technique for mapping a BPMN diagram to a specific execution language. This is an important validation of the standard and proof- of-concept, but I do not believe it should be a part of this specification. Subject: RE: AI-5 Date: Thu, 2 Mar 2006 14:43:58 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI-5 Thread-Index: AcY9de/S/st3rsc5TuqV0B+KMlOkggAhpEGg From: "Giraud Jean-Luc" To: "Rob Bartel" , X-OriginalArrivalTime: 02 Mar 2006 13:44:36.0079 (UTC) FILETIME=[71BCC7F0:01C63DFF] X-Scanned-By: MIMEDefang 2.38 Hi Rob, I fully agree with your comments. All attributes that are implementation-driven should be removed from the spec. BPEL mapping is a nice sample to prove that BPMN objects are meaningful in an execution context but that's all. I believe we must be careful to not couple BPMN with any execution layer. However, we still have to check that BPMN is able to support the description of executable processes even if some extensions must be provided by tools. Thanks for this usefull request for clarification. Jean-Luc -----Message d'origine----- De : Rob Bartel [mailto:Rob.Bartel@igrafx.com] Envoyé : mercredi 1 mars 2006 22:20 À : bpmn-ftf@omg.org Objet : AI-5 I have been doing some work to resolve AI-5, which is to identify attributes included solely for BPEL4WS. In a preliminary scan of the spec, I only found three for which the text specifically says they were included for BPEL4WS: On the Process object: SuppressJoinFailure EnableInstanceCompensation On the Property object (though the description appears to be incorrect) Correlation However, my history with this spec suggests that many more would not be there were it not necessary to map to BPEL4WS. In some cases entire objects seem to be there largely to support mapping to BPEL4WS. Full disclosure: I am a member of the school of thought that says that BPMN should be a standard for a diagramming methodology, the focus of which is to communicate in a diagram the sequencing, parallelism and synchronization of a business process - including exceptional conditions. In other words, "when does work get done". I do not believe it enhances the standard to specify attributes that have no standardized effect on the diagram displayed and no standardized effect on the time at which things are occur. I also do not understand why execution in BPEL drives so many of the hidden attributes, but other interesting attributes are omitted including resource allocation and simulation modeling data. Before completing this action item, I'd like to understand the sense of the group about what attributes/objects should make the list. Let me pick on two in particular, to give you an idea of what I'm wondering. The Expression object is standardized as a String and a statement that it can be evaluated to produce a result. The only standardized use that is ever made of this object, so far as I am aware, is when emitting BPEL4WS. If we were to remove BPEL4WS from the spec I believe a strong argument could be made that it does not enhance the document as a "standard" to describe an attribute as an uninterpreted string, but still it is a string that is intended to have specific meaning. Since it does not affect the displayed diagram it does not standardize communication between humans. Since it does not have any standard semantics it does not standardize communications between tools. The second target I'll pick on is WebService. This object clearly has the same problems that Expression does, but additionally it is not at all clear that it is a good idea to embed the choice of web service, or indeed any implementation at all, in the process model. It seems to me a vendor and it's toolset should be able to support the standard but provide alternative ways of deployment-time mapping of the work done at an activity to a specific real-world or simulated implementation. The market can determine if that's a better solution or not, but I do not believe sufficient attention or debate has been given to this object and its uses in BPMN to claim that we can *standardize* how it's done. This email is a request for clarification on the question of what AI-5 is intended to accomplish, and I would appreciate responses to that. However, it is also a ill-disguised plea to consider removing a significant number of attributes and objects, particularly those that were added late in the 1.0 specification process with relatively little debate or review to support mapping to BPEL4WS. I would very much prefer to see them moved to a separate paper that describes one technique for mapping a BPMN diagram to a specific execution language. This is an important validation of the standard and proof- of-concept, but I do not believe it should be a part of this specification. Subject: RE: AI-5 Date: Thu, 2 Mar 2006 14:49:23 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI-5 Thread-Index: AcY9de/S/st3rsc5TuqV0B+KMlOkggAhpEGgAADP7fA= From: "LONJON Antoine" To: "Giraud Jean-Luc" , "Rob Bartel" , It was also a recommendation from the OMG Architecture Board that the BPEL mapping and all corresponding elements should not be part of the "official" BPMN specification It is the job of the FTF to fulfill this requirement -------------------------------------------------------------------------------- From: Giraud Jean-Luc [mailto:jlgiraud@axway.com] Sent: Thursday, March 02, 2006 2:44 PM To: Rob Bartel; bpmn-ftf@omg.org Subject: RE: AI-5 Hi Rob, I fully agree with your comments. All attributes that are implementation-driven should be removed from the spec. BPEL mapping is a nice sample to prove that BPMN objects are meaningful in an execution context but that's all. I believe we must be careful to not couple BPMN with any execution layer. However, we still have to check that BPMN is able to support the description of executable processes even if some extensions must be provided by tools. Thanks for this usefull request for clarification. Jean-Luc -----Message d'origine----- De : Rob Bartel [mailto:Rob.Bartel@igrafx.com] Envoyé : mercredi 1 mars 2006 22:20 À : bpmn-ftf@omg.org Objet : AI-5 I have been doing some work to resolve AI-5, which is to identify attributes included solely for BPEL4WS. In a preliminary scan of the spec, I only found three for which the text specifically says they were included for BPEL4WS: On the Process object: SuppressJoinFailure EnableInstanceCompensation On the Property object (though the description appears to be incorrect) Correlation However, my history with this spec suggests that many more would not be there were it not necessary to map to BPEL4WS. In some cases entire objects seem to be there largely to support mapping to BPEL4WS. Full disclosure: I am a member of the school of thought that says that BPMN should be a standard for a diagramming methodology, the focus of which is to communicate in a diagram the sequencing, parallelism and synchronization of a business process - including exceptional conditions. In other words, "when does work get done". I do not believe it enhances the standard to specify attributes that have no standardized effect on the diagram displayed and no standardized effect on the time at which things are occur. I also do not understand why execution in BPEL drives so many of the hidden attributes, but other interesting attributes are omitted including resource allocation and simulation modeling data. Before completing this action item, I'd like to understand the sense of the group about what attributes/objects should make the list. Let me pick on two in particular, to give you an idea of what I'm wondering. The Expression object is standardized as a String and a statement that it can be evaluated to produce a result. The only standardized use that is ever made of this object, so far as I am aware, is when emitting BPEL4WS. If we were to remove BPEL4WS from the spec I believe a strong argument could be made that it does not enhance the document as a "standard" to describe an attribute as an uninterpreted string, but still it is a string that is intended to have specific meaning. Since it does not affect the displayed diagram it does not standardize communication between humans. Since it does not have any standard semantics it does not standardize communications between tools. The second target I'll pick on is WebService. This object clearly has the same problems that Expression does, but additionally it is not at all clear that it is a good idea to embed the choice of web service, or indeed any implementation at all, in the process model. It seems to me a vendor and it's toolset should be able to support the standard but provide alternative ways of deployment-time mapping of the work done at an activity to a specific real-world or simulated implementation. The market can determine if that's a better solution or not, but I do not believe sufficient attention or debate has been given to this object and its uses in BPMN to claim that we can *standardize* how it's done. This email is a request for clarification on the question of what AI-5 is intended to accomplish, and I would appreciate responses to that. However, it is also a ill-disguised plea to consider removing a significant number of attributes and objects, particularly those that were added late in the 1.0 specification process with relatively little debate or review to support mapping to BPEL4WS. I would very much prefer to see them moved to a separate paper that describes one technique for mapping a BPMN diagram to a specific execution language. This is an important validation of the standard and proof- of-concept, but I do not believe it should be a part of this specification. **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Subject: RE: AI-5 Date: Thu, 2 Mar 2006 09:39:33 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI-5 Thread-Index: AcY9de/S/st3rsc5TuqV0B+KMlOkggAhpEGgAADP7fAAAdebEQ== From: "Rob Bartel" To: "LONJON Antoine" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k22EaDkf020468 I was "otherwise engaged" when Action Item 5 was created, but it was my impression that it is part of the preliminary work needed to address at least Issues 9139/9240 and 9322/9323. That's why I took it on, to get those issues moving - it is going to take a fair amount of editing, and we should get started sooner rather than later on it. I'm relieved to hear it's considered a "requirement" in addition to an "issue". -----Original Message----- From: LONJON Antoine [mailto:antoine.lonjon@mega.com] Sent: Thu 3/2/2006 5:49 AM To: Giraud Jean-Luc; Rob Bartel; bpmn-ftf@omg.org Subject: RE: AI-5 It was also a recommendation from the OMG Architecture Board that the BPEL mapping and all corresponding elements should not be part of the "official" BPMN specification It is the job of the FTF to fulfill this requirement ________________________________ From: Giraud Jean-Luc [mailto:jlgiraud@axway.com] Sent: Thursday, March 02, 2006 2:44 PM To: Rob Bartel; bpmn-ftf@omg.org Subject: RE: AI-5 Hi Rob, I fully agree with your comments. All attributes that are implementation-driven should be removed from the spec. BPEL mapping is a nice sample to prove that BPMN objects are meaningful in an execution context but that's all. I believe we must be careful to not couple BPMN with any execution layer. However, we still have to check that BPMN is able to support the description of executable processes even if some extensions must be provided by tools. Thanks for this usefull request for clarification. Jean-Luc -----Message d'origine----- De : Rob Bartel [mailto:Rob.Bartel@igrafx.com] Envoyé : mercredi 1 mars 2006 22:20 À : bpmn-ftf@omg.org Objet : AI-5 I have been doing some work to resolve AI-5, which is to identify attributes included solely for BPEL4WS. In a preliminary scan of the spec, I only found three for which the text specifically says they were included for BPEL4WS: On the Process object: SuppressJoinFailure EnableInstanceCompensation On the Property object (though the description appears to be incorrect) Correlation However, my history with this spec suggests that many more would not be there were it not necessary to map to BPEL4WS. In some cases entire objects seem to be there largely to support mapping to BPEL4WS. Full disclosure: I am a member of the school of thought that says that BPMN should be a standard for a diagramming methodology, the focus of which is to communicate in a diagram the sequencing, parallelism and synchronization of a business process - including exceptional conditions. In other words, "when does work get done". I do not believe it enhances the standard to specify attributes that have no standardized effect on the diagram displayed and no standardized effect on the time at which things are occur. I also do not understand why execution in BPEL drives so many of the hidden attributes, but other interesting attributes are omitted including resource allocation and simulation modeling data. Before completing this action item, I'd like to understand the sense of the group about what attributes/objects should make the list. Let me pick on two in particular, to give you an idea of what I'm wondering. The Expression object is standardized as a String and a statement that it can be evaluated to produce a result. The only standardized use that is ever made of this object, so far as I am aware, is when emitting BPEL4WS. If we were to remove BPEL4WS from the spec I believe a strong argument could be made that it does not enhance the document as a "standard" to describe an attribute as an uninterpreted string, but still it is a string that is intended to have specific meaning. Since it does not affect the displayed diagram it does not standardize communication between humans. Since it does not have any standard semantics it does not standardize communications between tools. The second target I'll pick on is WebService. This object clearly has the same problems that Expression does, but additionally it is not at all clear that it is a good idea to embed the choice of web service, or indeed any implementation at all, in the process model. It seems to me a vendor and it's toolset should be able to support the standard but provide alternative ways of deployment-time mapping of the work done at an activity to a specific real-world or simulated implementation. The market can determine if that's a better solution or not, but I do not believe sufficient attention or debate has been given to this object and its uses in BPMN to claim that we can *standardize* how it's done. This email is a request for clarification on the question of what AI-5 is intended to accomplish, and I would appreciate responses to that. However, it is also a ill-disguised plea to consider removing a significant number of attributes and objects, particularly those that were added late in the 1.0 specification process with relatively little debate or review to support mapping to BPEL4WS. I would very much prefer to see them moved to a separate paper that describes one technique for mapping a BPMN diagram to a specific execution language. This is an important validation of the standard and proof- of-concept, but I do not believe it should be a part of this specification. **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Subject: RE: AI-5 Date: Thu, 2 Mar 2006 09:18:40 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI-5 Thread-Index: AcY9de/S/st3rsc5TuqV0B+KMlOkggAiEsXwAAe3+8A= From: "Pete Rivett" To: "Cummins, Fred A" , "Rob Bartel" , UML2 models expressions as pair(s) of (body, language) - so that the spec does not hard code an assumption about the language used. This also allows multiple languages to be used - e.g. an English version and an OCL version of the same logical expression. Pete -------------------------------------------------------------------------------- From: Cummins, Fred A [mailto:fred.cummins@eds.com] Sent: Thursday, March 02, 2006 2:43 PM To: Rob Bartel; bpmn-ftf@omg.org Subject: RE: AI-5 Rob, My view is that BPMN should be platform independent, and I consider BPEL to be a "platform." As for the two examples: The expression object might be used for expression of conditions that would be platform independent. However, as an "expression" it is implied that it will be in a particular language. This will be resolved in BPDM where there is some discussion regarding the form of conditions--one option is that they are expressed in natural language (for business people). The alternative would be to base it on another language like OCL. We might look at the approach being taken in the Production Rules Representation (PRR) specification. The "WebService" specification certainly sounds like the model would be platform specific, so I would agree that it should not be part of BPMN. Fred -------------------------------------------------------------------------------- From: Rob Bartel [mailto:Rob.Bartel@igrafx.com] Sent: Wednesday, March 01, 2006 4:20 PM To: bpmn-ftf@omg.org Subject: AI-5 I have been doing some work to resolve AI-5, which is to identify attributes included solely for BPEL4WS. In a preliminary scan of the spec, I only found three for which the text specifically says they were included for BPEL4WS: On the Process object: SuppressJoinFailure EnableInstanceCompensation On the Property object (though the description appears to be incorrect) Correlation However, my history with this spec suggests that many more would not be there were it not necessary to map to BPEL4WS. In some cases entire objects seem to be there largely to support mapping to BPEL4WS. Full disclosure: I am a member of the school of thought that says that BPMN should be a standard for a diagramming methodology, the focus of which is to communicate in a diagram the sequencing, parallelism and synchronization of a business process - including exceptional conditions. In other words, "when does work get done". I do not believe it enhances the standard to specify attributes that have no standardized effect on the diagram displayed and no standardized effect on the time at which things are occur. I also do not understand why execution in BPEL drives so many of the hidden attributes, but other interesting attributes are omitted including resource allocation and simulation modeling data. Before completing this action item, I'd like to understand the sense of the group about what attributes/objects should make the list. Let me pick on two in particular, to give you an idea of what I'm wondering. The Expression object is standardized as a String and a statement that it can be evaluated to produce a result. The only standardized use that is ever made of this object, so far as I am aware, is when emitting BPEL4WS. If we were to remove BPEL4WS from the spec I believe a strong argument could be made that it does not enhance the document as a "standard" to describe an attribute as an uninterpreted string, but still it is a string that is intended to have specific meaning. Since it does not affect the displayed diagram it does not standardize communication between humans. Since it does not have any standard semantics it does not standardize communications between tools. The second target I'll pick on is WebService. This object clearly has the same problems that Expression does, but additionally it is not at all clear that it is a good idea to embed the choice of web service, or indeed any implementation at all, in the process model. It seems to me a vendor and it's toolset should be able to support the standard but provide alternative ways of deployment-time mapping of the work done at an activity to a specific real-world or simulated implementation. The market can determine if that's a better solution or not, but I do not believe sufficient attention or debate has been given to this object and its uses in BPMN to claim that we can *standardize* how it's done. This email is a request for clarification on the question of what AI-5 is intended to accomplish, and I would appreciate responses to that. However, it is also a ill-disguised plea to consider removing a significant number of attributes and objects, particularly those that were added late in the 1.0 specification process with relatively little debate or review to support mapping to BPEL4WS. I would very much prefer to see them moved to a separate paper that describes one technique for mapping a BPMN diagram to a specific execution language. This is an important validation of the standard and proof- of-concept, but I do not believe it should be a part of this specification. Date: Thu, 02 Mar 2006 14:20:09 -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: LONJON Antoine CC: bpmn-ftf@omg.org Subject: Re: AI-5 Antoine wrote: It was also a recommendation from the OMG Architecture Board that the BPEL mapping and all corresponding elements should not be part of the "official" BPMN specification It is the job of the FTF to fulfill this requirement It is possible that the politics have now changed. At one time, BPMN was seen (by proponents of both BPMN and BPEL) as the graphical representation of choice for BPEL specifications. To remove BPEL entirely from the BPMN spec is an injustice to those who supported the work for that reason. Whether to make the BPEL mapping "normative" (an optional compliance point) or "informative" is (I think) the issue we must address in the FTF. The AB's "recommendation" was not a mandate. To make the mapping normative we need to ask three questions: (1) will any participating BPMN tool vendor implement the BPEL mapping? (2) is the adopted BPMN model with BPEL attributes "complete" or at least sufficient to represent the majority of BPEL specifications in practice? (3) is the BPMN->BPEL mapping stable and generally agreed to? If the answer to any of these is No, the BPMN->BPEL mapping cannot reasonably be made normative. In particular, if no one answers YES to (1), this is all an academic exercise. And if there are multiple Yes answers to (1), we can probably determine what the answer to (3) is. If the answer to (2) is "No, but the FTF can easily fix that", and the other two are clearly Yes, we should consider that there is still a strong basis for a normative specification and get the interested parties to do the needed work. The standards managers and standards writers on the FTF can assist in developing a normative mapping, but the leadership has to come from a set of vendors who want a normative mapping standard. And if you happen to be one of those, don't be depressed by the email thus far. As I count it, that is just 4 answers of No to question (1), out of 30+ implementors. -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, and have not been reviewed by any Government authority." Subject: RE: AI-5 Date: Thu, 2 Mar 2006 14:04:13 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AI-5 Thread-Index: AcY+LnnYvek9IvFDQF6NFeHO1uScEgABO8Xg From: "Cummins, Fred A" To: , "LONJON Antoine" Cc: X-OriginalArrivalTime: 02 Mar 2006 20:05:08.0569 (UTC) FILETIME=[9AF64490:01C63E34] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k22Jv2fI026300 Ed, My understanding was that the AB approved BPMN on the condition that the BPEL mapping not be normative and that moving it to the appendix was required to make it clear that it is not part of the normative spec and ensure that the normative spec stands on its own. As a proof of concept, some vendors might choose to implement this mapping. However, it is my belief that others might choose to use a different mapping that is better aligned to the way they have implemented BPEL to achieve desired proprietary differentiation. We should view BPMN as platform independent and BPEL as a language implemented in different products, i.e., platforms. Fred >-----Original Message----- >From: Ed Barkmeyer [mailto:edbark@nist.gov] >Sent: Thursday, March 02, 2006 2:20 PM >To: LONJON Antoine >Cc: bpmn-ftf@omg.org >Subject: Re: AI-5 > >Antoine wrote: > >> It was also a recommendation from the OMG Architecture Board >that the >> BPEL mapping and all corresponding elements should not be >part of the >> "official" BPMN specification It is the job of the FTF to >fulfill this >> requirement > >It is possible that the politics have now changed. >At one time, BPMN was seen (by proponents of both BPMN and >BPEL) as the graphical representation of choice for BPEL >specifications. >To remove BPEL entirely from the BPMN spec is an injustice to >those who supported the work for that reason. >Whether to make the BPEL mapping "normative" (an optional >compliance point) or "informative" is (I think) the issue we >must address in the FTF. The AB's "recommendation" was not a mandate. > >To make the mapping normative we need to ask three questions: >(1) will any participating BPMN tool vendor implement the BPEL mapping? >(2) is the adopted BPMN model with BPEL attributes "complete" >or at least sufficient to represent the majority of BPEL >specifications in practice? >(3) is the BPMN->BPEL mapping stable and generally agreed to? > >If the answer to any of these is No, the BPMN->BPEL mapping >cannot reasonably be made normative. In particular, if no one >answers YES to (1), this is all an academic exercise. And if >there are multiple Yes answers to (1), we can probably >determine what the answer to (3) is. > >If the answer to (2) is "No, but the FTF can easily fix that", >and the other two are clearly Yes, we should consider that >there is still a strong basis for a normative specification >and get the interested parties to do the needed work. > >The standards managers and standards writers on the FTF can >assist in developing a normative mapping, but the leadership >has to come from a set of vendors who want a normative mapping >standard. And if you happen to be one of those, don't be >depressed by the email thus far. As I count it, that is just >4 answers of No to question (1), out of 30+ implementors. > >-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, > and have not been reviewed by any Government authority." > Date: Thu, 02 Mar 2006 13:15:25 -0800 From: Monica J Martin Subject: Re: AI-5 To: Rob Bartel , bpmn-ftf@omg.org X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Rob, I've chosen a brief response relative to three questions you posed. I've also included Ugo Corda and Dale Moberg (Ugo for his BPMN experience and Dale because of his process interest in eBusiness). Thanks. bartel: ...On the Process object: SuppressJoinFailure EnableInstanceCompensation mm1: The latter has been deleted in WS-BPEL v2.0 because the reasons for it being there originally were confused. I don't know if this information lends itself to the discussion, however. ...Before completing this action item, I'd like to understand the sense of the group about what attributes/objects should make the list. Let me pick on two in particular, to give you an idea of what I'm wondering. The Expression object is standardized as a String and a statement that it can be evaluated to produce a result. The only standardized use that is ever made of this object, so far as I am aware, is when emitting BPEL4WS. If we were to remove BPEL4WS from the spec I believe a strong argument could be made that it does not enhance the document as a "standard" to describe an attribute as an uninterpreted string, but still it is a string that is intended to have specific meaning. Since it does not affect the displayed diagram it does not standardize communication between humans. Since it does not have any standard semantics it does not standardize communications between tools. mm1: Expressions are important for assisting in guiding the business process. For example, similar to Fred Cummins's comment, the expressions are part of the conditions important to transitions to/from business activities. The second target I'll pick on is WebService. This object clearly has the same problems that Expression does, but additionally it is not at all clear that it is a good idea to embed the choice of web service, or indeed any implementation at all, in the process model. It seems to me a vendor and it's toolset should be able to support the standard but provide alternative ways of deployment-time mapping of the work done at an activity to a specific real-world or simulated implementation. The market can determine if that's a better solution or not, but I do not believe sufficient attention or debate has been given to this object and its uses in BPMN to claim that we can *standardize* how it's done. mm1: This is related to the question I asked on how to represent accurately (and in a manner relevant to a business analyst) that an activity mapped to another service that executed a particular capability in that activity. The use of an association, grouping or embedded process may or may not be appropriate to visualize this. However, it may serve a purpose to visualize, perhaps a different levels, that process (depending on decisions in this group). We found it valuable to visualize that business transaction activities could be mapped to invocable services (that may have been seen as an activity in and of themselves). See our use case regarding the joint activity and an OperationMapping. This email is a request for clarification on the question of what AI-5 is intended to accomplish, and I would appreciate responses to that. However, it is also a ill-disguised plea to consider removing a significant number of attributes and objects, particularly those that were added late in the 1.0 specification process with relatively little debate or review to support mapping to BPEL4WS. I would very much prefer to see them moved to a separate paper that describes one technique for mapping a BPMN diagram to a specific execution language. This is an important validation of the standard and proof- of-concept, but I do not believe it should be a part of this specification. mm1: Not to enter to this debate, reiterate a point that should these mappings remain even if incomplete, those that exist should be accurate. This will increase understanding and adoption. Thanks. Subject: BPEL and conformance (was RE: AI-5) Date: Thu, 2 Mar 2006 15:46:40 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BPEL and conformance (was RE: AI-5) Thread-Index: AcY+LoF3kYx0Y19jT5qzDukiw7HMiQAAoozl From: "Rob Bartel" To: , "LONJON Antoine" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k22KcSQ8027056 For full disclosure purposes, I am a person who has implemented BPMN to BPEL mapping, or more accurately iGrafx process model to BPEL mapping. The iGrafx model is (now) almost a superset of BPMN, but very little of the superset was used in the mapping. This work was done over the course of several months about 18 months ago. It is that experience that results in the position I have on this subject, and my perspective on the BPMN hidden attributes in general. I believe it also represents the position of my company (Corel/iGrafx), but assume my statements are personal opinion unless I say otherwise! I used section 6 and appendix B, and occasionally the example in section 7 of the BPMI spec (11, B and 12 in the OMG revision of it) to inform my work, but quickly found too many errors (at least as I understood the intended semantics) and omissions to consider it normative. It was then that I adopted the position that section 6 was an important and validating example of how BPMN can be mapped into one execution model, but should not be consider prescriptive. What I considered normative was the described behavior of the BPMN graphical elements and sequence and message flow. When my understanding of that conflicted with the behavior of the mapping to BPEL I did not feel constrained by section 6. The biggest problem, in my mind, of mapping human-drawn flowcharts to BPEL is that BPEL is limited in the number of process "topologies" that it can represent within a single process. Two examples in particular: it does not handle intersecting loops or loops that spawn tokens that exit the loop. Both of these occur frequently enough in human-drawn flowcharts (I use the word "flowcharts" instead of "process maps" here because the latter has more than one meaning) that we get significant push-back from users when told that they need to redesign or repartition their process. "I understand my process, I've done it that way for years, and don't tell me I need to redraw my process to match your software implementation constraints." While it is technically possible, of course, to create and deploy enough BPEL processes/services to implement virtually any flowchart, doing so automatically is a challenging project. Just automaticaly encapsulating a subset of feedback loop topologies was plenty difficult for this programmer. (as an aside, BPEL DOES make inclusive-OR join semantics precise, for that subset of token flow it supports) Our position with our customers is that "if you have standardized on BPEL as a platform, then you have to live within the constraints of BPEL in your diagrams." If you take that position then making a mapping to BPEL a normative part of the BPMN standard is a little hard to justify I think. In contrast to the thought provoking cases Ed case mentioned on the phone call today, BPEL is not a superset of BPMN semantics in the way that C++ is to IDL or Java is to WSDL. Given a hypothetical language that did contain all the execution semantics of BPMN I could support making a mapping to it normative. To get to (finally) Ed's points below - I believe I agree with them completely. A couple of specific responses: 1) Responding to: "It is possible that the politics have now changed. At one time, BPMN was seen (by proponents of both BPMN and BPEL) as the graphical representation of choice for BPEL specifications." I was unaware of this. I was under the impression that the BPEL mapping was done to validate the usability of BPMN for describing executable processes. Given Ed's statement, I agree with his conclusion that it would now be an injustice to remove the BPEL mapping to an external white paper. 2) My (and I think iGrafx) position on Ed's three questions: To make the mapping normative we need to ask three questions: (1) will any participating BPMN tool vendor implement the BPEL mapping? We have implemented a BPEL mapping that we think accurately implements the BPMN behaviors described in the text, where a single BPEL process supports those behaviors. It does not always adhere to the mapping presented in the spec. Sometimes this is due to errors we believe are in the mapping, and sometimes it is due to my believing there was a better way to do it. (2) is the adopted BPMN model with BPEL attributes "complete" or at least sufficient to represent the majority of BPEL specifications in practice? clearly not, and I think I can provide several examples if it's useful. But I believe Ed misspoke, and that the better question is "Is the adopted BPMN model with BPEL attributes complete enough to allow an equivalent BPEL specification, for those process topologies that BPEL supports". I believe the answer to that is yes, although without more specification of some of the attributes a certain amount of "vendor interpretation" (read "proprietary") is required. In other words, I think the question is whether BPMN is big enough to be useful as an executable specification for a large number of real-world processes, not whether it can represent all possible (or most possible) BPEL programs. BPMN is a methodology for modeling business processes, it is not intended for a BPEL program editor. (3) is the BPMN->BPEL mapping stable and generally agreed to? I believe it could be made stable, with a substantial but not overwhelming amount of work, and certainly more than editorial change. I don't know if it could be made "generally agreed to", but I suspect it could. Unfortunately, I have to report my impressions and conclusions from a year and a half ago rather than being able to provide a list of errors or ambiguities in the spec. If the FTF proceeds to a decision that the mapping is to be made normative (a step I will obviously strongly resist) I will go through and try to extract those that I believe are wrong, ambiguous or unclear. Rob -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Thu 3/2/2006 11:20 AM To: LONJON Antoine Cc: bpmn-ftf@omg.org Subject: Re: AI-5 Antoine wrote: > It was also a recommendation from the OMG Architecture Board > that the BPEL mapping and all corresponding elements should not > be part of the "official" BPMN specification > It is the job of the FTF to fulfill this requirement It is possible that the politics have now changed. At one time, BPMN was seen (by proponents of both BPMN and BPEL) as the graphical representation of choice for BPEL specifications. To remove BPEL entirely from the BPMN spec is an injustice to those who supported the work for that reason. Whether to make the BPEL mapping "normative" (an optional compliance point) or "informative" is (I think) the issue we must address in the FTF. The AB's "recommendation" was not a mandate. To make the mapping normative we need to ask three questions: (1) will any participating BPMN tool vendor implement the BPEL mapping? (2) is the adopted BPMN model with BPEL attributes "complete" or at least sufficient to represent the majority of BPEL specifications in practice? (3) is the BPMN->BPEL mapping stable and generally agreed to? If the answer to any of these is No, the BPMN->BPEL mapping cannot reasonably be made normative. In particular, if no one answers YES to (1), this is all an academic exercise. And if there are multiple Yes answers to (1), we can probably determine what the answer to (3) is. If the answer to (2) is "No, but the FTF can easily fix that", and the other two are clearly Yes, we should consider that there is still a strong basis for a normative specification and get the interested parties to do the needed work. The standards managers and standards writers on the FTF can assist in developing a normative mapping, but the leadership has to come from a set of vendors who want a normative mapping standard. And if you happen to be one of those, don't be depressed by the email thus far. As I count it, that is just 4 answers of No to question (1), out of 30+ implementors. -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, and have not been reviewed by any Government authority." -- This message has been scanned for viruses and Subject: AI-5, 32, 33, 34 - BPMN Attributes table Date: Wed, 22 Mar 2006 15:50:59 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: AI-5, 32, 33, 34 - BPMN Attributes table Thread-Index: AcZN8lCjN7q7rNtVTx6pyvDoXi1Dsg== From: "Rob Bartel" To: Attached is what I said last Thursday I'd have "in the next day or two"... This is not a carefully checked table, but I think it's pretty close to correct. I've attempted to define the criteria I chose to categorize "Diagram", "Model" and "Platform", but the difference between P and M may be point-of-view. I also attempted to mark "ambiguous" attributes. I defined those to mean attributes that would affect model behavior and that have essentially no guidance as to how to format them. I called enumerated string attributes non-ambiguous, although us tool vendors might hotly question that. The point here is that tool vendors will need to cooperate on the values in order to exchange equivalent behaviors because there is no specification other than English text about their contents. The right-most column is more notes to myself than you, but feel free to try to interpret them. Some thoughts occurred to me as I did this: 1) Identity is not well defined. In particular, Name is not specified as unique in any scope in places where it is implied to be an identifier - e.g. Participant. 2) We probably should have a statement that enumerated strings must be exchanged with values that have the exact spelling and capitalization of the spec. 3) I did this by going through Appendix B. I cannot vouch for the equivalence between the tables in B and the tables scattered throughout the text of the spec, although I believe it to be pretty good. 4) I caught some errors, but this was not a proof-reading pass. Many of the attributes descriptions I didn't need to look at, so they haven't all been read (at least by me.) Rob To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9139 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Tue, 12 Sep 2006 15:07:15 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 09/12/2006 16:07:16, Serialize complete at 09/12/2006 16:07:16 This is planned for Ballot 3. I'll be sending out Ballot 3 soon. Along with the ballot I'll post a new version of the spec, with the proposed changes. http://www.bpmn.org/FTF/Issues/Issue%209139.htm Issue 9139: BPEL Mapping Extraction to Appendix Description: Part 1: Section 6 of the current specification should be moved as an appendix Part 2: All attributes related to the BPEL mapping should be removed. Discussion Notes: We thought that the first half of this issue should be done, but that second half might not be done or required a lot of work (perhaps too much for the FTF). Thus, it should be split into two Issues (AI-4). Based on the discussion from the Concall on March 2, 2006, and the completion of AI-18, AI-4 was withdrawn and we decided to resolved the issue as it stands and not to pass it on to other Issues. Basically, we thought that we could do both parts of this Issue. We recommend that the Issue be resolved through a revision in the text (see below). The resolution must take into account the concerns raised in Issues 9322 and 9323. Suggested Resolution 1: Resolved: Section 11 of the Specification will be moved to Annex A. The current contents of Annex A will remain as a section. Other changes will be made to make the specification more readable (in terms of BPEL mapping) following the concerns raised in Issues 9322 and 9323. Revised Text: a) Rename the title of Annex A from "E-Mail Voting Process BPEL4WS" to "Mapping to BPEL4WS" b) Add a new introductory paragraph with the text: "This annex provides information and examples about how BPMN will map to BPEL4WS 1.1." c) Move Section 11 of the Specification to Appendix A, within the first Heading2 item ("A.1"). All the section, table, and figure headings need to be updated. d) Section A.1, first paragraph: append the paragraph with the following two sentences: "Note that there are known issues with the mapping as specified. Fixes to these issues will be incorporated in a later revision of the specification." e) Copy Section 12 ("BPMN by Example") and paste into the second Heading2 item ("A.2") of Appendix A. All the section, table, figure, and example headings need to be updated. Section 12 will remain, but the mapping sections will be removed. f) Section A.2 (new), first paragraph: Append first sentence with the text "...and will extend Section 11 by adding information about how the example Process will map to BPEL4WS." g) Demote the current title ("E-Mail Voting Process BPEL4WS") to Heading2 and move to the third Heading2 item ("A.3"). h) Remove the current A.1 section title ("Introduction")--but leave the first paragraph of that section (which will now be in A.3) and the table that follows. i) Section 11 (was 12), first paragraph: remove last sentence. j) Section 11 (was 12): remove Section 11.1.1, Section 11.2.1, Section 11.3.1, and Section 11.4.1. k) Section 6.2, page 6, first paragraph: replace "...is a normative part..." with "...is a non-normative part..." l) Section 6.3, page 6: remove fifth paragraph m) Section 6.3, page 6, sixth (now fifth) paragraph: remove the following text from the end of the sentence: " and its particular mapping to BPEL4WS" n) Section 6.3, page 6: replace the seventh (now sixth) paragraph with: "Annex A: Mapping to BPEL4WS provides a mechanism for converting a Business Process to a BPEL4WS document, provides and example of Process mapping, and provides a full sample of BPEL4WS code based on the example process mapping." o) Section 7, page 9, third paragraph. second sentence: replace "...formal mapping..." with "...mapping..." p) Section 8.6.1, page 30, Table 8.7, third row (ProcessType), second column: remove all the sentences after the second sentence. q) Section 8.6.1, page 31, Table 8.7: remove the fourth row (SuppressJoinFailure) and the fifth row (EnableInstanceCompensation) on the page from the table. These rows will remain in a table in Appendix A. r) Section B.2, page 243, Table B.2: remove the third row (SuppressJoinFailure) and the fourth row (EnableInstanceCompensation) on the page from the table. These rows will remain in a table in Appendix A. s) Section 9, page 33, first paragraph: reset the reference to the BPEL mapping section to Appendix A t) Section 9.5.2, Sub-Section "Event-Based," page 75, first paragraph, first sentence: replace the text "...will map to the BPEL4WS pick." to "...was derived from the BPEL4WS pick." u) Section 9.5.2, Sub-Section "Event-Based," page 76: move last paragraph on page to Section A.1.6 (new section as per above changes), Sub-Section "Event-Based," page TBD, after the section title. v) Section 9.6, page 86, first paragraph: remove the first two sentences. w) Section 9.6, page 86, second paragraph: remove the first two sentences. x) Section 9.6, page 86: combine the first two paragraphs into one paragraph. y) Section 9.7.4, page 96, last paragraph on page: remove the following text from the end of the last sentence: " and do not map to any BPEL4WS elements." z) Section 10.2.1, Sub-Section "Joining Flow," page 114: remove last paragraph on page. aa) Section 10.2.1, Sub-Section "Merging Flow," page 121: remove first paragraph on page. bb) Section 10.2.2, page 131, last paragraph on page: remove first sentence. cc) Section 10.2.2, page 132, first paragraph on page (continues from last page): remove sentence. dd) Section 10.2.2, page 132: combine the first two paragraphs. Date: Mon, 23 Oct 2006 13:59:01 -0400 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: edbark@nist.gov CC: BPMN FTF Subject: Re: Issue 9139 BPMN Conformance clause draft v3 X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Ed Barkmeyer wrote: I think this covers what we wanted to put in the conformance clause. It is a rewrite because of all of the wordsmithing, but most of the content is the same. Well, no. I left off the fixes to 6.2 that directly address the Issue. The proposed text revisions to 6.2 are now included at the end. -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, and have not been reviewed by any Government authority." BPMN-Issue9139-Conformance-v3.rtf Conformance (Issue 9139) After the third paragraph of Clause 1 Scope, add 2 new paragraphs: This version of the specification does not specify a mechanism for exchange of BPMN diagrams. 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. Note: Exchange of models of BPMN process semantics and diagrams is the subject of other ongoing standards activities. 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. Replace Clause 2 with: 2 Conformance 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 8-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 8-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. Note: 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: . 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. In Clause 6.2, a) Renumber and retitle Clause 6.2 to: 6.1.2 Abbreviations b) Delete the first paragraph. Subject: RE: BPMN FTF Issues Ballot 3 Date: Fri, 6 Oct 2006 10:23:49 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BPMN FTF Issues Ballot 3 Thread-Index: Acbek8PDNVo1XHllTOqDEqkt++G4WAKzprnw From: "Pete Rivett" To: "Stephen A White" , Adaptive votes YES to all the proposed resolutions except 9562 to which it votes NO. I also have some suggestions which can be applied as editorial changes without affecting the ballot. 9562 does not seem to address the issue as raised (e.g. duration relative to a previous step in a process), and does not add any more precision. It in fact seems to duck the issue with a very unspecific definition of TimeDateExpression which seems to be intended for representing both absolute dates and recurring ones. And does not seem to provide a means of referencing another element in a process. Does any real ExpressionLanguage exist that permits this together with a unit of measure? For issue 9139 I suggest adding the editorial change of adding "(Informative)" after the title of Appendix A. This is standard practice for any appendix in an OMG specification. For Issue 9896 I suggest the editorial change of making the name of the attribute consistent: in some places it is 'Performer' and in others 'Performers'. It's also odd that though the attribute is defined to represent a 'resource' that all the examples represent humans or groups thereof. Could resources not include equipment, facilities? For Issue 9905, again editorial, the Disposition should not be Duplicate since it's a distinct issue despite it being addressed by the resolution to 9936: the Disposition should instead be Resolved. 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 -------------------------------------------------------------------------------- From: Stephen A White [mailto:wstephe@us.ibm.com] Sent: Friday, September 22, 2006 11:09 PM To: bpmn-ftf@omg.org Subject: BPMN FTF Issues Ballot 3 BPMN FTF Issues Ballot 3 The Ballot will end on close of business October 6, 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 (9139): Yes ___ No ___ Abstain ___ Resolution Vote (9411): Yes ___ No ___ Abstain ___ Resolution Vote (9561): Yes ___ No ___ Abstain ___ Resolution Vote (9562): Yes ___ No ___ Abstain ___ Resolution Vote (9564): Yes ___ No ___ Abstain ___ Resolution Vote (9896): Yes ___ No ___ Abstain ___ Resolution Vote (9897): Yes ___ No ___ Abstain ___ Resolution Vote (9905): Yes ___ No ___ Abstain ___ Resolution Vote (9722): Yes ___ No ___ Abstain ___ Resolution Vote (9893): Yes ___ No ___ Abstain ___ Issue descriptions and resolutions are below (you can vote below also)... ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Issue 9139: BPEL Mapping Extraction to Appendix http://www.bpmn.org/FTF/Issues/Issue%209139.htm Description: Part 1: Section 6 of the current specification should be moved as an appendix Part 2: All attributes related to the BPEL mapping should be removed. Resolution: Resolved: Section 11 of the Specification will be moved to Annex A. The current contents of Annex A will remain as a section. Other changes will be made to make the specification more readable (in terms of BPEL mapping) following the concerns raised in Issues 9322 and 9323. Revised Text: a) Rename the title of Annex A from "E-Mail Voting Process BPEL4WS" to "Mapping to BPEL4WS" b) Add a new introductory paragraph with the text: "This annex provides information and examples about how BPMN will map to BPEL4WS 1.1." c) Move Section 11 of the Specification to Appendix A, within the first Heading2 item ("A.1"). All the section, table, and figure headings need to be updated. d) Section A.1, first paragraph: append the paragraph with the following two sentences: "Note that there are known issues with the mapping as specified. Fixes to these issues will be incorporated in a later revision of the specification." e) Copy Section 12 ("BPMN by Example") and paste into the second Heading2 item ("A.2") of Appendix A. All the section, table, figure, and example headings need to be updated. Section 12 will remain, but the mapping sections will be removed. f) Section A.2 (new), first paragraph: Append first sentence with the text "...and will extend Section 11 by adding information about how the example Process will map to BPEL4WS." g) Demote the current title ("E-Mail Voting Process BPEL4WS") to Heading2 and move to the third Heading2 item ("A.3"). h) Remove the current A.1 section title ("Introduction")--but leave the first paragraph of that section (which will now be in A.3) and the table that follows. i) Section 11 (was 12), first paragraph: remove last sentence. j) Section 11 (was 12): remove Section 11.1.1, Section 11.2.1, Section 11.3.1, and Section 11.4.1. k) Section 6.2, page 6, first paragraph: replace "...is a normative part..." with "...is a non-normative part..." l) Section 6.3, page 6: remove fifth paragraph m) Section 6.3, page 6, sixth (now fifth) paragraph: remove the following text from the end of the sentence: " and its particular mapping to BPEL4WS" n) Section 6.3, page 6: replace the seventh (now sixth) paragraph with: "Annex A: Mapping to BPEL4WS provides a mechanism for converting a Business Process to a BPEL4WS document, provides and example of Process mapping, and provides a full sample of BPEL4WS code based on the example process mapping." o) Section 7, page 9, third paragraph. second sentence: replace "...formal mapping..." with "...mapping..." p) Section 8.6.1, page 30, Table 8.7, third row (ProcessType), second column: remove all the sentences after the second sentence. q) Section 8.6.1, page 31, Table 8.7: remove the fourth row (SuppressJoinFailure) and the fifth row (EnableInstanceCompensation) on the page from the table. These rows will remain in a table in Appendix A. r) Section B.2, page 243, Table B.2: remove the third row (SuppressJoinFailure) and the fourth row (EnableInstanceCompensation) on the page from the table. These rows will remain in a table in Appendix A. s) Section 9, page 33, first paragraph: reset the reference to the BPEL mapping section to Appendix A t) Section 9.5.2, Sub-Section "Event-Based," page 75, first paragraph, first sentence: replace the text "...will map to the BPEL4WS pick." to "...was derived from the BPEL4WS pick." u) Section 9.5.2, Sub-Section "Event-Based," page 76: move last paragraph on page to Section A.1.6 (new section as per above changes), Sub-Section "Event-Based," page TBD, after the section title. v) Section 9.6, page 86, first paragraph: remove the first two sentences. w) Section 9.6, page 86, second paragraph: remove the first two sentences. x) Section 9.6, page 86: combine the first two paragraphs into one paragraph. y) Section 9.7.4, page 96, last paragraph on page: remove the following text from the end of the last sentence: " and do not map to any BPEL4WS elements." z) Section 10.2.1, Sub-Section "Joining Flow," page 114: remove last paragraph on page. aa) Section 10.2.1, Sub-Section "Merging Flow," page 121: remove first paragraph on page. bb) Section 10.2.2, page 131, last paragraph on page: remove first sentence. cc) Section 10.2.2, page 132, first paragraph on page (continues from last page): remove sentence. dd) Section 10.2.2, page 132: combine the first two paragraphs. ee) Section B.2, page 242, Table B.2, third row (ProcessType), second column: remove all the sentences after the second sentence. ff) Section B.11.7, page 270, Table B.47, third row (Correlation), second column: remove second paragraph. gg) Section B.11.11, page 271, Table B.51, first row (Participant), second column: remove second sentence. Resolution Vote (9139): Yes ___ No ___ Abstain ___ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Issue 9411: Section 12 of the specification should be moved as is to an appendix http://www.bpmn.org/FTF/Issues/Issue%209411.htm Description: Section 12 of the specification should be moved as is to an appendix, based on its focus on mapping to BPEL. In addition, the text from that section that does not deal with BPEL mapping should be copied and placed within the Overview section (Section 7). Resolution: Resolved: A copy of Section 12 shall be placed in Appendix A (which deals with BPEL mapping). The parts of Section 12 that deal with the mapping to BPEL will be removed, so that the section only contains a sample process. These changes have been specified in the resolution of Issue 9139, so no further changes are required. Revised Text: None Resolution Vote (9411): Yes ___ No ___ Abstain ___ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 9561: Message Flow ordering along Pool (abst process) is modeled only graphically http://www.bpmn.org/FTF/Issues/Issue%209561.htm Description: Message Flow ordering along Pool (abstract process) is modeled only graphically. A specification of in/out indices to message flows is a solution. Otherwise it's impossible to tell from the model order of message receive/send for certain pool. 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 Resolution Vote (9561): Yes ___ No ___ Abstain ___ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 9562: Time intervals modeling is imprecise http://www.bpmn.org/FTF/Issues/Issue%209562.htm Description: Time intervals modeling is imprecise. Specification lists related field as TimeDate:Date and TimeCycle:String. In fact, modelers typically need to specify time interval since some event (e.g. starting the enclosing process). Enumerated cycle values (daily/weekly/monthly) or cycle interval and number of cycles would also be handy. Consider the way Outlook calendars handles regular meeting appointments. It would be nice to model advance reminder as separate entity (timer event occurring before another scheduled event). Resolution: Resolved: The definition of the Timer Trigger attributes TimeDate and TimeCycle will be updated to of a (new) type DateTimeExpression, which will be a sub-type of Expression. Predefined Process and activity Properties (such as ActivityStartTime) are also required to facilitate the definition of appropriate expressions. Changes to the specification for the updates of the Timer Trigger attributes are listed below. Changes to the specification for the addition of Predefined Process and activity Properties will be listed in the resolution of Issue 9563. Revised Text: Section 9.3.2, Table 9.5, page 38, and Section B.5.2, Table B.6, page 245: a) Fourth Row ("TimeDate"), First Column: Replace "Date" with "TimeDateExpression" b) Fifth Row ("TimeCycle"), First Column: Replace "String" with "TimeDateExpression" Section 9.3.4, Table 9.9, page 46, and Section B.5.4, Table B.8, page 247: c) Fifth Row ("TimeDate"), First Column: Replace "Date" with "TimeDateExpression" d) Sixth Row ("TimeCycle"), First Column: Replace "String" with "TimeDateExpression" Section B.11.9, page 271: e) Add new Section after B.11.9 with the section title: "TimeDateExpression" d) Add a paragraph after the title: "The TimeDateExpression supporting element is a sub-type of the Expression Element (Expression on page XXX) and uses all the attributes of the Expression Element." Resolution Vote (9561): Yes ___ No ___ Abstain ___ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 9564: Reference Subprocess http://www.bpmn.org/FTF/Issues/Issue%209564.htm Description: Reference Subprocess defines Input/OutputPropertyMaps attributes to define actual parameters, while there is no clean way to define formal parameters of the process. Resolution: Resolved: The handling of both Properties and Artifacts for inputs, outputs, and mapping between process levels, needs to be both generalized and synchronized. The following changes to the specification will be made: Section 8.6, Table 8.7, page 30: a) Add two new Rows after the last row (Properties). The rows will have the following content: InputSets (0-n) : Input The InputSets attribute defines the data requirements for input to the Process. Zero or more InputSets MAY be defined. Each Input set is sufficient to allow the Process to be performed (if it has first been instantiated by the appropriate signal arriving from an incoming Sequence Flow). Further details about the definition of an Input can be found in Section B.11.4, .Input,. on page XXX. OutputSets (0-n) : Output The OutputSets attribute defines the data requirements for output from the Process. Zero or more OutputSets MAY be defined. At the completion of the Process, only one of the OutputSets may be produced--It is up to the implementation of the Process to determine which set will be produced. However, the IORules attribute MAY indicate a relationship between an OutputSet and an InputSet that started the Process. Further details about the definition of an Output can be found in Section B.11.7, .Output,. on page XXX. b) The same changes will apply to Section B.2, Table B.2, page 242: Section 9.4.1, Table 9.10, page 50: c) Third Row, second column: append the following sentence to the paragraph "Further details about the definition of an Input can be found in Section B.11.4, .Input,. on page XXX." (This section is a new section) d) Fourth row: Delete fourth row. It will be updated in section B.11.4 (the new section). e) Fifth Row (now fourth), second column: append the following sentence to the paragraph "Further details about the definition of an Output can be found in Section B.11.7, .Input,. on page XXX." (This section is a new section) f) Sixth row (now fifth): Delete fifth row. It will be updated in section B.11.7 (the new section). e) The same changes will apply to Section B.6.1, Table B.9, page 249: Section 9.4.2, Sub-Section "Independent Sub-Process," Table 9.15, page 58: g) Third Row, First Column: Change "InputPropertyMaps" to "InputMaps" h) Third Row, Second Column: replace the current paragraph with the following paragraph: "Multiple input mappings MAY be made between the Independent Sub-Process and the Process referenced by this object. These mappings are in the form of an expression. A specific mapping expression MUST specify the mapping of Properties between the two Processes OR the mapping of Artifacts between the two Processes." i) Fourth Row, First Column: Change "OutputPropertyMaps" to "OutputMaps" j) Fourth Row, Second Column: replace the current paragraph with the following paragraph: "Multiple output mappings MAY be made between the Independent Sub-Process and the Process referenced by this object. These mappings are in the form of an expression. A specific mapping expression MUST specify the mapping of Properties between the two Processes OR the mapping of Artifacts between the two Processes." k) The same changes will apply to Section B.6.2, Sub-Section "Independent Sub-Process," Table B.14, page 253: Section B.11 Add a new section after section B.11.3 (Expression): l) The section title will be: "Input." m) The first Paragraph will be: "The following table displays the set of attributes of an Input, which is used in the definition of common attributes for Activities and for attributes of a Process." n) Then will follow a table, with the title: "Input Attributes" o) The table will have the following contents: Attributes Description ArtifactInput (0-n) : Artifact Zero or more ArtifactInputs MAY be defined for each InputSet. For the combination of ArtifactInputs and PropertyInputs, there MUST be at least one item defined for the Input. An ArtifactInput is an Artifact, usually a Document Object. Note that the Artifacts MAY also be displayed on the diagram and MAY be connected to the activity through an Association--however, it is not required for them to be displayed. PropertyInput (0-n) : Property Zero or more PropertyInputs MAY be defined for each InputSet. For the combination of ArtifactInputs and PropertyInputs, there MUST be at least one item defined for the Input. Add a new section after section B.11.5 (Object): p) The section title will be: "Output." q) The first Paragraph will be: "The following table displays the set of attributes of an Output, which is used in the definition of common attributes for Activities and for attributes of a Process." r) Then will follow a table, with the title: "Output Attributes" s) The table will have the following contents: Attributes Description ArtifactOutput (0-n) : Artifact Zero or more ArtifactOutputs MAY be defined for each OutputSet. For the combination of ArtifactOutputs and PropertyOutputs, there MUST be at least one item defined for the Output. An ArtifactOutput is an Artifact, usually a Document Object. Note that the Artifacts MAY also be displayed on the diagram and MAY be connected to the activity through an Association--however, it is not required for them to be displayed. PropertyOutput (0-n) : Property Zero or more PropertyOutputs MAY be defined for each OutputSet. For the combination of ArtifactOutputs and PropertyOutputs, there MUST be at least one item defined for the Output. Resolution Vote (9564): Yes ___ No ___ Abstain ___ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Issue 9896: Performers http://www.bpmn.org/FTF/Issues/Issue%209896.htm Description: Currently, only User Tasks and Manual Tasks can have performers. Suggest this be extended to other types of tasks, that is, allow association of performers with any kind of task. Resolution: Resolved: The Performer attribute will be made more general to apply to all types of activities. Thus, the attribute will be moved from the User and Manual Tasks to the Activity and Process elements. Revised Text: Section 8.6.1,Table 8.7, page 30: a) add row after the "GraphicalElements..." row: b) the first column of the new row will contain the text: "Performers (0-n) : String" c) the second column of the new row will contain the text: "One or more Performers MAY be entered. The Performer attribute defines the resource that will be participating in the Process. The Performers entry could be in the form of a specific individual, a group, an organization role or position, or an organization." Section B.2,Table B.2, page 242: d) add the same row as above after the "GraphicalElements..." Section 9.4.1,Table 9.10, page 50: e) add row after the "Status..." row: f) the first column of the new row will contain the text: "Performers (0-n) : String" g) the second column of the new row will contain the text: "One or more Performers MAY be entered. The Performer attribute defines the resource that will perform or will be participating in the activity. The Performer entry could be in the form of a specific individual, a group, an organization role or position, or an organization." Section B.6.1,Table B.9, page 249: h) add the same row as above after the "Status..." Section 9.4.3,Sub-Section "User Task," Table 9.21, page 66: i) remove the first row ("Performers...") Section 9.4.3,Sub-Section "Manual Task," page 67: j) remove first paragraph (of this page) k) remove Table 9.23 Resolution Vote (9896): Yes ___ No ___ Abstain ___ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Issue 9897: Role association to subprocesses http://www.bpmn.org/FTF/Issues/Issue%209897.htm Description: Currently, roles can only be associated with tasks, via the "performers" attribute. However, it is common to associate roles with subprocesses. In the case of a subprocess, the meaning is one of responsibility for the subprocess rather than who performs the subprocess. Suggested Resolution: Resolved: The Performer attribute will be made more general to apply to Sub-Processes as well as Tasks. The resolution of Issue 9896 will achieve the same result. Thus, no further changes to the specification are required. Revised Text: None Resolution Vote (9897): Yes ___ No ___ Abstain ___ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Issue 9905: Start Events with triggers on a subprocess http://www.bpmn.org/FTF/Issues/Issue%209905.htm Description: What are the semantics of a Start Event with a Trigger in of a subprocess? When will the subprocess be instantiated ... when it's parent process sends it a token or when it receives the event trigger? Suggested Resolution: Duplicate: This is a duplicate Issue since another Issue (9936) will address this topic. Revised Text: None Resolution Vote (9905): Yes ___ No ___ Abstain ___ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Issue 9722: The Property attribute definition is inconsistent http://www.bpmn.org/FTF/Issues/Issue%209722.htm Description: The attribute definitions for Property are unclear/inconsistent. The attribute names are "Type" and "Correlation". But in the Description for Correlation, the text refers to "ConditionType" and "Condition Expression": "If the ConditionType attribute is set to Expression, then the ConditionExpression attribute must be defined." It is unclear what this is referring to. Possible notation: a square, similar to the stop button on a tape player. Suggested Resolution: Resolved: The definition of the Correlation attribute will be updated and a new attribute for "Value" shall be added to the Property element. Also, the description for the Type attribute will be updated to make the reference to hierachical Properties more general. These change will result in the text revisions below: Revised Text: a) Section B.11.7, page 270, Table B.47, second row (Type), second column: replace second sentence with the following sentence: "Properties may be defined hierarchically." b) Section B.11.7, page 270, Table B.47: add a new row after the second row with the following contents: Value (0-1) : Expression Each Property MAY have a Value specified. c) Section B.11.7, page 270, Table B.47, third row (now the fourth row - Correlation), first column: remove the first line ("[Type = "Set" only]") d) Section B.11.7, page 270, Table B.47, third row (now the fourth row - Correlation), second column: replace the first paragraph with the following text: "If the Correlation attribute is set to True, then the Property is marked to be used for correlation (e.g., for incoming Messages)." Note that the second sentence is set to be removed in the resolution of Issue 9139. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Issue 9893: Definition of Expression http://www.bpmn.org/FTF/Issues/Issue%209893.htm Description: The definition of "Expression", as given in section B.11.3, is ambiguous. More clarification is needed in the spec. Suggested Resolution: Resolved: The description for an Expression will be updated. The Expression attribute (of the Expression element) will be renamed to ExpressionBody. The ExpressionLanguage attribute of the Business Process Diagram element will be moved to the Expression Element. Thus, there is more flexibility in defining expressions and their language. This will result in the text revisions below: Revised Text: a) Section 8.5, page 29, Table 8.6: remove third row on page (ExpressionLanguage) b) Section B.1, page 241, Table B.1: remove sixth row (ExpressionLanguage) c) Section B.11.3, page 269, Table B.43, first row, first column: replace "Expression" with "ExpressionBody" d) Section B.11.3, page 269, Table B.43, first row, second column: replace the current description with the following text: "The ExpressionBody MUST be entered to provide the text of the expression, which will be written in the language defined by the ExpressionLanguage attribute." e) Section B.11.3, page 269, Table B.43: append row to table with the following contents: ExpressionLanguage : String A Language MUST be provided to identify the language of the ExpressionBody. The value of the ExpressionLanguage should follow the naming conventions for the version of the specified language. To: Ed Barkmeyer Cc: bpmn-ftf@omg.org Subject: Re: BPMN FTF Issues Ballot 3 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Mon, 9 Oct 2006 09:56:24 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/09/2006 10:56:28, Serialize complete at 10/09/2006 10:56:28 >*9139: I concur with the intent here, but I am concerned that the definitions >of Attributes removed from the normative tables in Annex B should not >disappear entirely. Since we moved the mapping tables from Clause 11, they >are mentioned in those tables, but they are nowhere else documented as >additional Attributes of the BPMN Objects. The resolution says there will be >a table of these things in Annex A, but there isn't -- there are only the >mapping tables. For example, the definition of SuppressJoinFailure is deleted >from Process and from (old) Annex B, and the new Annex only says what it is >mapped to, not what it is/means. Ed, Good point. 9139 did pass, so the changes have been (will be) made. We should add another issue to return the moved attributes description in Annex A. I can send that in, if you like. -Steve Ed Barkmeyer 10/06/2006 01:03 PM Please respond to edbark@nist.gov To bpmn-ftf@omg.org cc Subject Re: BPMN FTF Issues Ballot 3 NIST (Barkmeyer) ballot on BPMN FTF Issues Ballot 3 Resolution Vote (9139): Yes ___ No _x_ Abstain ___ Resolution Vote (9411): Yes _x_ No ___ Abstain ___ Resolution Vote (9561): Yes _x_ No ___ Abstain ___ Resolution Vote (9562): Yes _x_ No ___ Abstain ___ Resolution Vote (9564): Yes _x_ No ___ Abstain ___ Resolution Vote (9896): Yes _x_ No ___ Abstain ___ Resolution Vote (9897): Yes _x_ No ___ Abstain ___ Resolution Vote (9905): Yes _x_ No ___ Abstain ___ Resolution Vote (9722): Yes _x_ No ___ Abstain ___ Resolution Vote (9893): Yes _x_ No ___ Abstain ___ Please show that the formal disposition of each of these issues is as follows: 9139- Resolved with technical changes 9411- Resolved with technical changes 9561- Deferred 9562- Resolved with technical changes 9564- Resolved with technical changes 9896- Resolved with technical changes 9897- Resolved by 9896 9905- Duplicates 9936 9722- Resolved with editorial changes? 9893- Resolved with technical changes *9139: I concur with the intent here, but I am concerned that the definitions of Attributes removed from the normative tables in Annex B should not disappear entirely. Since we moved the mapping tables from Clause 11, they are mentioned in those tables, but they are nowhere else documented as additional Attributes of the BPMN Objects. The resolution says there will be a table of these things in Annex A, but there isn't -- there are only the mapping tables. For example, the definition of SuppressJoinFailure is deleted from Process and from (old) Annex B, and the new Annex only says what it is mapped to, not what it is/means. -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 Date: Wed, 11 Oct 2006 11:03:08 -0400 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: Stephen A White CC: bpmn-ftf@omg.org Subject: Re: BPMN FTF Issues Ballot 3 X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Stephen A White wrote: *9139: I concur with the intent here, but I am concerned that the attributes ... Ed, Good point. 9139 did pass, so the changes have been (will be) made. We should add another issue to return the moved attributes description in Annex A. I can send that in, if you like. Actually, give me a chance (we have about 3 weeks) to work with Peter Walker and other interested parties, and we can probably make a corrected set of BPEL attributes to put in Annex A. And that should be the resolution to some issue we already have. (That wouldn't solve all the problems, because there will be limitations on the BPMN process graphs that can be transformed to BPEL, and we need to document that. But that depends on the resolutions of some of the process semantics issues, and we won't have time.) -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, Date: Mon, 23 Oct 2006 11:39:15 -0400 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 Subject: BPMN Issue 9139 Conformance (modified draft) X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No I fixed two bugs in the writeup from last Thursday. BTW, this completes Action Item 35 (6 months later). -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 BPMN-Issue9139-Conformance.rtf Conformance (Issue 9139) After the third paragraph of Clause 1 Scope, add 2 new paragraphs: This version of the specification does not specify a mechanism for exchange of BPMN diagrams. 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. Note: Exchange of models of BPMN process semantics and diagrams is the subject of other ongoing standards activities. Replace Clause 2 with: 2 Conformance 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 8-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 8-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. Note: 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: . 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. dangerous content, and is believed to be clean.