Issue 3444: MOF 1.3 Incorrect attribute order in diagrams (mof-rtf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: In the MOF 1.3 Specification, the order of attributes shown in some of the diagrams and their descriptions is inconsistent with the order given in the XML and IDL. Particularly, GeneralizableElement and AssociationEnd show attributes out of order. The diagrams, explanative text, XML and IDL should all show features in the same order because order is relevant when determining the order of parameters passed to a create operation. A diagram showing attributes out of order can lead one to pass creation arguments in the wrong order. Recommendation: fix the order in the diagrams and explanations. Resolution: see above Revised Text: Redraw all UML diagrams in Chapter 3 as Framemaker diagram. Ensure that all attributes and operations are in the correct order. Reorder the Head3 subsections in Chapter 3 as required to match the order of the IDL and XMI. Actions taken: March 22, 2000: received issue December 3, 2001: closed issue Discussion: Resolution: Check Chapter 3 to ensure that the order of attributes, operations and other elements shown in the diagrams and as implied by the subsection headings is the same as defined in the IDL and XMI. Note: this does not change the meaning of the specification since the order shown in the element order in the diagrams and the text is already explicitly stated to be non-normative. However, these changes should make the specification easier to read. End of Annotations:===== From: "Baisley, Donald E" To: issues@omg.org Subject: MOF 1.3 Incorrect attribute order in diagrams Date: Wed, 22 Mar 2000 18:17:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 9oh!!?1I!!08Ae9DVe!! In the MOF 1.3 Specification, the order of attributes shown in some of the diagrams and their descriptions is inconsistent with the order given in the XML and IDL. Particularly, GeneralizableElement and AssociationEnd show attributes out of order. The diagrams, explanative text, XML and IDL should all show features in the same order because order is relevant when determining the order of parameters passed to a create operation. A diagram showing attributes out of order can lead one to pass creation arguments in the wrong order. Recommendation: fix the order in the diagrams and explanations. Don Baisley Unisys X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 3444: MOF 1.3 Incorrect attribute order in diagrams Mime-Version: 1.0 Date: Wed, 13 Jun 2001 16:06:46 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: cd!"!#$nd96N#e95]*!! > Source: Unisys (Mr. Don Baisley, Donald.Baisley@unisys.com) > Nature: Uncategorized Issue > Severity: > Summary: In the MOF 1.3 Specification, the order of attributes shown > in > some of the diagrams and their descriptions is inconsistent with the > order > given in the XML and IDL. Particularly, GeneralizableElement and > AssociationEnd > show attributes out of order. The diagrams, explanative text, XML > and IDL > should all show features in the same order because order is relevant > when > determining the order of parameters passed to a create operation. A > diagram > showing attributes out of order can lead one to pass creation > arguments in > the wrong order. > > Recommendation: fix the order in the diagrams and explanations. Proposed Resolution: Close with no action. Discussion: Up to now, the people writing the spec had taken the view that the order in which attributes (and operations, etc) appeared in the diagrams was not significant. Similarly, the order in which they were described. Indeed, section 3.2.1 contains the following text: "Note - except where stated, the order in which Section 3.4 introduces classes and their component features is not normative. The normative order is defined in the XMI for the MOF Model which may be found in Appendix A. This order determines the order in which elements appear in the generated IDL, and is in theory significant." Changes could be made to make the text and XMI line up, but the current wording of the spec makes it clear that this would be a purely editorial exercise. From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Issue 3444: MOF 1.3 Incorrect attribute order in diagrams Date: Wed, 13 Jun 2001 19:45:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: b!\d9@-?!!J!Z!!HF]d9 Since attribute order defines the order of parameters to construct operations, if we decide to show attributes in diagrams in the wrong order and tell people to look in the XML file for the correct order, then we should also show our operation parameters in the wrong order and tell people to look in the XMI file to discover the correct order. On the other hand, perhaps we should simply show ordered things in their official order so that people can plainly see what order things are in. Correcting the order in the specification is not a lot of work. Regards, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Tuesday, June 12, 2001 11:07 PM To: mof-rtf@omg.org Subject: Re: Issue 3444: MOF 1.3 Incorrect attribute order in diagrams > Source: Unisys (Mr. Don Baisley, Donald.Baisley@unisys.com) > Nature: Uncategorized Issue > Severity: > Summary: In the MOF 1.3 Specification, the order of attributes shown > in > some of the diagrams and their descriptions is inconsistent with the > order > given in the XML and IDL. Particularly, GeneralizableElement and AssociationEnd > show attributes out of order. The diagrams, explanative text, XML and IDL > should all show features in the same order because order is relevant when > determining the order of parameters passed to a create operation. A diagram > showing attributes out of order can lead one to pass creation arguments in > the wrong order. > > Recommendation: fix the order in the diagrams and explanations. Proposed Resolution: Close with no action. Discussion: Up to now, the people writing the spec had taken the view that the order in which attributes (and operations, etc) appeared in the diagrams was not significant. Similarly, the order in which they were described. Indeed, section 3.2.1 contains the following text: "Note - except where stated, the order in which Section 3.4 introduces classes and their component features is not normative. The normative order is defined in the XMI for the MOF Model which may be found in Appendix A. This order determines the order in which elements appear in the generated IDL, and is in theory significant." Changes could be made to make the text and XMI line up, but the current wording of the spec makes it clear that this would be a purely editorial exercise. X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Baisley, Donald E" cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 3444: MOF 1.3 Incorrect attribute order in diagrams In-Reply-To: Message from "Baisley, Donald E" of "Wed, 13 Jun 2001 19:45:34 EST." Mime-Version: 1.0 Date: Thu, 14 Jun 2001 11:07:27 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: XK*e92KPe9@a$!!XZ:e9 Don, > Since attribute order defines the order of parameters to construct > operations, if we decide to show attributes in diagrams in the wrong > order > and tell people to look in the XML file for the correct order, then > we > should also show our operation parameters in the wrong order and > tell people > to look in the XMI file to discover the correct order. That's silly. Users can / do look at the IDL to determine the order of the parameters. There's no need for users to look at the XMI. I agree it would be a good idea to correct this, but I think it is (in OMG parlance) an editorial issue. In other words, I'm recommending that the MOF RTF could / should resolve that it doesn't need to concern itself with this because it is not a substantive change to the spec. I (or whoever does the editing of the MOF 1.4 framemaker doc) can fix this with no further input from the RTF. It will be fiddly and painful because we'll need to change those damn Rational Rose diagrams :-(. But, assuming that I do the editing, it will happen. -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Issue 3444: MOF 1.3 Incorrect attribute order in diagrams Date: Wed, 13 Jun 2001 20:25:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: k?!!!+2`!!6%`d9A'He9 Steve, I'm glad you noticed I was being silly. I have a MOF Model diagram at my desk. I refer to it when coding Java or IDL. I don't need to look at generated interfaces because I know the generation pattern. I'm model-driven. Thanks for volunteering to fix the problem when editing. It will make life easier for some of us who are more apt to look at the diagram than the XML or generated interfaces. Regards, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Wednesday, June 13, 2001 6:07 PM To: Baisley, Donald E Cc: mof-rtf@omg.org; crawley@dstc.edu.au Subject: Re: Issue 3444: MOF 1.3 Incorrect attribute order in diagrams Don, > Since attribute order defines the order of parameters to construct > operations, if we decide to show attributes in diagrams in the wrong > order > and tell people to look in the XML file for the correct order, then > we > should also show our operation parameters in the wrong order and > tell people > to look in the XMI file to discover the correct order. That's silly. Users can / do look at the IDL to determine the order of the parameters. There's no need for users to look at the XMI. I agree it would be a good idea to correct this, but I think it is (in OMG parlance) an editorial issue. In other words, I'm recommending that the MOF RTF could / should resolve that it doesn't need to concern itself with this because it is not a substantive change to the spec. I (or whoever does the editing of the MOF 1.4 framemaker doc) can fix this with no further input from the RTF. It will be fiddly and painful because we'll need to change those damn Rational Rose diagrams :-(. But, assuming that I do the editing, it will happen. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 3444: MOF 1.3 Incorrect attribute order in diagrams Mime-Version: 1.0 From: Stephen Crawley Date: Fri, 22 Jun 2001 17:14:21 +1000 Sender: crawley@dstc.edu.au X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 0B/!!#H*e9Tb>!!4Ehd9 [Revised Resolution, as per teleconf of 15/6/2001] > Source: Unisys (Mr. Don Baisley, Donald.Baisley@unisys.com) > Nature: Uncategorized Issue > Severity: > Summary: In the MOF 1.3 Specification, the order of attributes shown > in > some of the diagrams and their descriptions is inconsistent with the > order > given in the XML and IDL. Particularly, GeneralizableElement and > AssociationEnd > show attributes out of order. The diagrams, explanative text, XML > and IDL > should all show features in the same order because order is relevant > when > determining the order of parameters passed to a create operation. A > diagram > showing attributes out of order can lead one to pass creation > arguments in > the wrong order. > > Recommendation: fix the order in the diagrams and explanations. Proposed Resolution: Check Chapter 3 to ensure that the order of attributes, operations and other elements shown in the diagrams and as implied by the subsection headings is the same as defined in the IDL and XMI. Note: this does not change the meaning of the specification since the order shown in the element order in the diagrams and the text is stated to be non-normative. However, these changes should make the specification easier to read. Proposed Text Changes: Redraw all UML diagrams in Chapter 3 as Framemaker diagram. Ensure that all attributes and operations are in the correct order. Reorder the Head3 subsections in Chapter 3 as required.