Issue 9329: Unclear what complete syntax is for an Attribute (bpmn-ftf) Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com) Nature: Uncategorized Issue Severity: Summary: 6.1.1 should show the complete syntax for an attribute e.g. as BNF. Resolution: Suggested Resolution: Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to the BPMN 2.0 RFP. Revised Text: None Disposition: Closed, deferred Revised Text: Actions taken: January 30, 2006: received issue July 18, 2008: closed issue Discussion: Discussion: 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. Disposition: Deferred End of Annotations:===== ubject: Further BPMN issues Date: Sun, 29 Jan 2006 21:34:26 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Further BPMN issues Thread-Index: AcYlXtWDZBGQwojvTguClGAOoc5ROQ== From: "Pete Rivett" To: , The remainder of those I raised in the AB review, again adjusted to the DAS numbering scheme. Issue E) Unclear what complete syntax is for an Attribute 6.1.1 should show the complete syntax for an attribute e.g. as BNF. 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 Date: Thu, 23 Mar 2006 14:40:35 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: bpmn-ftf@omg.org Subject: BPMN Issue 9329: Syntax for Attributes All, In today's telecon, we agreed that section 6.1.1 does not properly describe the syntax for attributes, and that we may want to make changes to the syntax used in the tables. A now-common variant of Backus-Naur Form (BNF) is used in a number of programming language standards, in the XML Recommendation, etc. This form has an ISO standard (10176?). In this BNF form, - a 'literal' is any sequence of characters enclosed in quotation marks. An occurrence of a literal means exactly those characters appear at that place. - a 'term' beginning with a letter denotes a 'non-terminal symbol', that is, a symbol that has its own possible values and representation rules. An occurrence of a term means any valid expansion of that term appears at that place. - a 'group' is a sequence of one or more literals, terms, repeat groups or optional groups. An occurrence of a group means at that place that set of things appears in exactly that order. - a 'parenthesized group' is a group enclosed in parentheses. It has the same meaning as the enclosed group. - an 'alternative group' is a sequence of two or more literals, terms, repeat groups or parenthesized groups separated by vertical stroke (|). An occurrence of an alternative group means that any one of the elements in the sequence can appear at that place. - an 'optional group' is a group enclosed in square brackets ([]). An occurrence of an optional group means that either the group occurs at that place or nothing occurs at that place. - a 'repeat group' is a parenthesized group followed by an asterisk (*). An occurrence of a repeat group means that zero or more occurrences of the group (as a group) can occur consecutively at that place. - a 'production' has the form: term = group . and it means that the permissible expansion of the term is the group. Using this form, the syntax currently used in BPMN to define an attribute is: attribute = attribute_name [multiplicity] [enumeration] [default] ":" datatype . where multiplicity = "(0-1)" | "(0-n)" | "(1-n)" . enumeration = "(" value ( "|" value )* ")" . default = value . and attribute_name, value and datatype are identifiers. In the form originally invented by John Backus (later Fortran) and Peter Naur (later Algol) for the International Algorithmic Language conference in 1956, the literals occur without delimiters, the terms appear in pointy brackets (<>), and the only operator is the "alternative" (!). So, for example: ::= ( ) . ::= ! | . is the original BNF for the above production. Now, Issue 9329 can be resolved by changing 6.1.1 to include the above "grammar" in some form of BNF with a pointer to the reference for the BNF form used. And no table needs to be changed. Frank and I suggested that a UML-like notation might be easier to read and understand, e.g. attribute = attribute_name ":" datatype [multiplicity] [ "=" default ] . or attribute = attribute_name [multiplicity] ":" datatype [ "=" default ] . where everything else is the same as above, except datatype = identifier | enumeration . The advantage of this approach is that it treats an enumerated type as a datatype and that it moves the default value to the end and gives it explicit punctuation. All of this makes reading the specification easier, but it does not change the content at all. But... this change would require: 3 changes to table B.2 1 change to table B.5 2 changes to table B.6 2 changes to table B.7 2 changes to table B.8 3 changes to table B.9 1 change to table B.10 2 changes to table B.11 1 change to table B.12 1 change to table B.13 1 change to table B.16 1 change to table B.17 1 change to table B.18 1 change to table B.19 1 change to table B.20 1 change to table B.24 1 change to table B.25 1 change to table B.26 1 change to table B.31 1 change to table B.33 2 changes to table B.34 2 changes to table B.38 1 change to table B.40 1 change to table B.41 3 changes to table B.46 1 change to table B.47 1 change to table B.50 and in each case, to the primary occurrence of the table in the body of specification. I'm not sure that this volume of changes is warranted, when it is solely to improve readability. -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, Reply-To: From: "Conrad Bock" To: , Subject: RE: BPMN Issue 9329: Syntax for Attributes Date: Thu, 23 Mar 2006 16:52:47 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZOvYyFmZhEiNi5RBGHiCnm4QrgVQABj+iA How about lifting the BNF from the UML spec? Make sure to use the latest, http://doc.omg.org/ptc/06-01-02. For the textual notation for Property, see p 130, PDF page 149. Conrad > -----Original Message----- > From: Ed Barkmeyer [mailto:edbark@nist.gov] > Sent: Thursday, March 23, 2006 2:41 PM > To: bpmn-ftf@omg.org > Subject: BPMN Issue 9329: Syntax for Attributes > > All, > > In today's telecon, we agreed that section 6.1.1 does not > properly describe > the syntax for attributes, and that we may want to make > changes to the syntax > used in the tables. > > A now-common variant of Backus-Naur Form (BNF) is used in a > number of > programming language standards, in the XML Recommendation, > etc. This form has > an ISO standard (10176?). In this BNF form, > - a 'literal' is any sequence of characters enclosed in > quotation marks. > An occurrence of a literal means exactly those characters > appear at that place. > - a 'term' beginning with a letter denotes a > 'non-terminal symbol', that is, > a symbol that has its own possible values and > representation rules. An > occurrence of a term means any valid expansion of that term > appears at that place. > - a 'group' is a sequence of one or more literals, terms, > repeat groups or > optional groups. An occurrence of a group means at that > place that set of > things appears in exactly that order. > - a 'parenthesized group' is a group enclosed in > parentheses. It has the > same meaning as the enclosed group. > - an 'alternative group' is a sequence of two or more > literals, terms, > repeat groups or parenthesized groups separated by vertical > stroke (|). An > occurrence of an alternative group means that any one of > the elements in the > sequence can appear at that place. > - an 'optional group' is a group enclosed in square > brackets ([]). An > occurrence of an optional group means that either the group > occurs at that > place or nothing occurs at that place. > - a 'repeat group' is a parenthesized group followed by > an asterisk (*). An > occurrence of a repeat group means that zero or more > occurrences of the group > (as a group) can occur consecutively at that place. > - a 'production' has the form: term = group . > and it means that the permissible expansion of the term is > the group. > > Using this form, the syntax currently used in BPMN to > define an attribute is: > attribute = attribute_name > [multiplicity] [enumeration] [default] ":" datatype . > where > multiplicity = "(0-1)" | "(0-n)" | "(1-n)" . > enumeration = "(" value ( "|" value )* ")" . > default = value . > and attribute_name, value and datatype are identifiers. > > In the form originally invented by John Backus (later > Fortran) and Peter Naur > (later Algol) for the International Algorithmic Language > conference in 1956, > the literals occur without delimiters, the terms appear in > pointy brackets > (<>), and the only operator is the "alternative" (!). So, > for example: > ::= ( ) . > ::= ! | . > is the original BNF for the above production. > > Now, Issue 9329 can be resolved by changing 6.1.1 to > include the above > "grammar" in some form of BNF with a pointer to the > reference for the BNF form > used. And no table needs to be changed. > > Frank and I suggested that a UML-like notation might be > easier to read and > understand, e.g. > attribute = attribute_name ":" datatype [multiplicity] [ > "=" default ] . > or > attribute = attribute_name [multiplicity] ":" datatype [ > "=" default ] . > where everything else is the same as above, except > datatype = identifier | enumeration . > > The advantage of this approach is that it treats an > enumerated type as a > datatype and that it moves the default value to the end and > gives it explicit > punctuation. All of this makes reading the specification > easier, but it does > not change the content at all. > > But... this change would require: > 3 changes to table B.2 > 1 change to table B.5 > 2 changes to table B.6 > 2 changes to table B.7 > 2 changes to table B.8 > 3 changes to table B.9 > 1 change to table B.10 > 2 changes to table B.11 > 1 change to table B.12 > 1 change to table B.13 > 1 change to table B.16 > 1 change to table B.17 > 1 change to table B.18 > 1 change to table B.19 > 1 change to table B.20 > 1 change to table B.24 > 1 change to table B.25 > 1 change to table B.26 > 1 change to table B.31 > 1 change to table B.33 > 2 changes to table B.34 > 2 changes to table B.38 > 1 change to table B.40 > 1 change to table B.41 > 3 changes to table B.46 > 1 change to table B.47 > 1 change to table B.50 > and in each case, to the primary occurrence of the table in > the body of > specification. > > I'm not sure that this volume of changes is warranted, when > it is solely to > improve readability. > > -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: Fri, 24 Mar 2006 10:50:52 -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: conrad.bock@nist.gov CC: bpmn-ftf@omg.org Subject: Re: BPMN Issue 9329: Syntax for Attributes Conrad Bock wrote: How about lifting the BNF from the UML spec? Make sure to use the latest, http://doc.omg.org/ptc/06-01-02. For the textual notation for Property, see p 130, PDF page 149. Using the UML attribute form directly requires us to change many more table entries, because UML places the multiplicity behind the data type, while the BPMN spec placed it in front of the data type, and uses hyphen for "to" rather than dot-dot. [BPMN thinks of the *attribute* as having the occurrences, i.e. 0..n instances of this attribute, which is analogous to the XML representation and to the UMLv2 view that an attribute is a kind of association, while the UML notation (from v1.x) considers the datatype to have the occurrences, i.e. the value of this attribute is an aggregation.] It's all editorial, and I would like consistency with UML, but OTOH, I don't see making a lot of needless work for Linda, either. We can take a straw poll in the FTF and pick one. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, Subject: RE: BPMN Issue 9329: Syntax for Attributes Date: Fri, 24 Mar 2006 18:15:13 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BPMN Issue 9329: Syntax for Attributes Thread-Index: AcZPWswnjhj5aXShQAuqPEZ90G1AWgACYFewAABg+GA= From: "LONJON Antoine" To: "Karl Frank" , , Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k2OH69EE000603 BPMN had its own way to use the term "attribute". It may be not well aligned with the definition of attribute in UML and MOF, but this doesn't matter. Moving to far in fixing an editing problem should no lead us to fix meanings and form of expression of these meanings in the BPMN spec. I feel this is not the role our FTF. Antoine -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, March 24, 2006 6:03 PM To: edbark@nist.gov; conrad.bock@nist.gov Cc: bpmn-ftf@omg.org Subject: RE: BPMN Issue 9329: Syntax for Attributes a positoin wrt straw poll: I like consistency in OMG languages on issues of syntax such as data type and multiplicity. Since it is the BPMN spec that is up for its first OMG release, it is the one that we should change to achieve consistency. In terms of products and users worldwide, it is also the UML and MOF specs that should set the precedent. conclusion: change BPMN t allign. just my opinion, let's hear more opinions. - Karl -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Friday, March 24, 2006 10:51 AM To: conrad.bock@nist.gov Cc: bpmn-ftf@omg.org Subject: Re: BPMN Issue 9329: Syntax for Attributes Conrad Bock wrote: > How about lifting the BNF from the UML spec? Make sure to use the > latest, http://doc.omg.org/ptc/06-01-02. > For the textual notation for Property, see p 130, PDF page 149. Using the UML attribute form directly requires us to change many more table entries, because UML places the multiplicity behind the data type, while the BPMN spec placed it in front of the data type, and uses hyphen for "to" rather than dot-dot. [BPMN thinks of the *attribute* as having the occurrences, i.e. 0..n instances of this attribute, which is analogous to the XML representation and to the UMLv2 view that an attribute is a kind of association, while the UML notation (from v1.x) considers the datatype to have the occurrences, i.e. the value of this attribute is an aggregation.] It's all editorial, and I would like consistency with UML, but OTOH, I don't see making a lot of needless work for Linda, either. We can take a straw poll in the FTF and pick one. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." **********************************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: BPMN Issue 9329: Syntax for Attributes Date: Fri, 24 Mar 2006 09:03:29 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BPMN Issue 9329: Syntax for Attributes Thread-Index: AcZPWswnjhj5aXShQAuqPEZ90G1AWgACYFew From: "Karl Frank" To: , Cc: X-OriginalArrivalTime: 24 Mar 2006 17:03:30.0530 (UTC) FILETIME=[E04FFC20:01C64F64] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k2OGtmuw000441 a positoin wrt straw poll: I like consistency in OMG languages on issues of syntax such as data type and multiplicity. Since it is the BPMN spec that is up for its first OMG release, it is the one that we should change to achieve consistency. In terms of products and users worldwide, it is also the UML and MOF specs that should set the precedent. conclusion: change BPMN t allign. just my opinion, let's hear more opinions. - Karl -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Friday, March 24, 2006 10:51 AM To: conrad.bock@nist.gov Cc: bpmn-ftf@omg.org Subject: Re: BPMN Issue 9329: Syntax for Attributes Conrad Bock wrote: > How about lifting the BNF from the UML spec? Make sure to use the > latest, http://doc.omg.org/ptc/06-01-02. > For the textual notation for Property, see p 130, PDF page 149. Using the UML attribute form directly requires us to change many more table entries, because UML places the multiplicity behind the data type, while the BPMN spec placed it in front of the data type, and uses hyphen for "to" rather than dot-dot. [BPMN thinks of the *attribute* as having the occurrences, i.e. 0..n instances of this attribute, which is analogous to the XML representation and to the UMLv2 view that an attribute is a kind of association, while the UML notation (from v1.x) considers the datatype to have the occurrences, i.e. the value of this attribute is an aggregation.] It's all editorial, and I would like consistency with UML, but OTOH, I don't see making a lot of needless work for Linda, either. We can take a straw poll in the FTF and pick one. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, To: bpmn-ftf@omg.org Cc: "LONJON Antoine" , conrad.bock@nist.gov, edbark@nist.gov, "Karl Frank" Subject: RE: BPMN Issue 9329: Syntax for Attributes X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Stephen A White Date: Fri, 24 Mar 2006 13:50:54 -0800 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.53HF743 | November 3, 2005) at 03/24/2006 14:50:56, Serialize complete at 03/24/2006 14:50:56 My understanding that this is really a formatting issue and the definition of the formatting (in section 6.1.1). I don't see a problem in using the same format as is used in other OMG documents as long as the content remains the same, it is understandable to readers, and it handles what we need (such as specifying default values). If this means that the tables have to be modified, then that would be OK, it is only some busywork. We can distribute that work within the team instead of dumping it all on Linda. -Steve "LONJON Antoine" 03/24/2006 09:15 AM To "Karl Frank" , , cc Subject RE: BPMN Issue 9329: Syntax for Attributes BPMN had its own way to use the term "attribute". It may be not well aligned with the definition of attribute in UML and MOF, but this doesn't matter. Moving to far in fixing an editing problem should no lead us to fix meanings and form of expression of these meanings in the BPMN spec. I feel this is not the role our FTF. Antoine -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, March 24, 2006 6:03 PM To: edbark@nist.gov; conrad.bock@nist.gov Cc: bpmn-ftf@omg.org Subject: RE: BPMN Issue 9329: Syntax for Attributes a positoin wrt straw poll: I like consistency in OMG languages on issues of syntax such as data type and multiplicity. Since it is the BPMN spec that is up for its first OMG release, it is the one that we should change to achieve consistency. In terms of products and users worldwide, it is also the UML and MOF specs that should set the precedent. conclusion: change BPMN t allign. just my opinion, let's hear more opinions. - Karl -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Friday, March 24, 2006 10:51 AM To: conrad.bock@nist.gov Cc: bpmn-ftf@omg.org Subject: Re: BPMN Issue 9329: Syntax for Attributes Conrad Bock wrote: > How about lifting the BNF from the UML spec? Make sure to use the > latest, http://doc.omg.org/ptc/06-01-02. > For the textual notation for Property, see p 130, PDF page 149. Using the UML attribute form directly requires us to change many more table entries, because UML places the multiplicity behind the data type, while the BPMN spec placed it in front of the data type, and uses hyphen for "to" rather than dot-dot. [BPMN thinks of the *attribute* as having the occurrences, i.e. 0..n instances of this attribute, which is analogous to the XML representation and to the UMLv2 view that an attribute is a kind of association, while the UML notation (from v1.x) considers the datatype to have the occurrences, i.e. the value of this attribute is an aggregation.] It's all editorial, and I would like consistency with UML, but OTOH, I don't see making a lot of needless work for Linda, either. We can take a straw poll in the FTF and pick one. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." **********************************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. ****************************************************************************** To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9329 X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 From: Stephen A White Date: Fri, 6 Oct 2006 16:13:54 -0700 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/06/2006 17:13:55, Serialize complete at 10/06/2006 17:13:55 This is intended for Ballot 4 Issue 9329: Unclear what complete syntax is for an Attribute Description: 6.1.1 should show the complete syntax for an attribute e.g. as BNF. Suggested 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