Issue 6158: Notation for attributes (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: The notation for attributes is given in Kernel::Classifier, but the abstract syntax for classifiers have no features Resolution: Revised Text: Actions taken: August 30, 2003: received issue March 9, 2005: closed issue Discussion: The abstract syntax for classifiers does have attributes, subsetting features, as is made clear in the resolution to 6156. This issue was submitted when the syntax diagram for classifier did not show /attribute, a defect fixed by the resolution to 6156. Disposition: Closed, no change End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Notation for attributes The notation for attributes is given in Kernel::Classifier, but the Subject: Proposed Classes issue resolution Date: Mon, 23 Feb 2004 09:14:15 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes of the UML 2 Superstructure FTF telecon - Feb. 18, 2004 Thread-Index: AcP3M2HWYCFfo0yJRH6DjLag4pjh7wC4xgiX From: "Karl Frank" To: "Branislav Selic" , X-OriginalArrivalTime: 23 Feb 2004 14:14:16.0789 (UTC) FILETIME=[52441050:01C3FA17] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i1NEEbre003190 All: please consider this issue resolution for the next ballot. - Karl and Joaquin OMG Issue No: 6158 Title: Notation for attributes Summary: The notation for attributes is given in Kernel::Classifier, but the abstract syntax for classifiers have no features. Discussion: Overview: The problem can be restated as The notation is given without a supporting diagram to show the abstract syntax of the modeling concept. The issue is correct in that Figure 22 currently omits the association with role attribute. The resolution is to add the association to Figure 22. Detailed Discussion Attribute is not a first class concept in UML 2, which is to say it is not specified using a class in the metamodel; instead it is specified using a role. The text at 7.8.1 Kernel::Classifier specifies that Classifier has an association, Classifier.attribute to Property. The properties in this role are the attributes of the classifier. The abstract syntax for Classifier does have attributes. Thus the notation is in the right place. This association (Classifier.attribute to Property) should be shown in the illustration, Figure 22. Change Figure 22 to show the association of the abstract syntax, Classifier.attribute to Property. The abstract syntax at 7.8.1 Kernel::Classifier specifies that Classifier has an association, Classifier.feature to Feature. The abstract syntax for Classifier does have features. This association is not shown in the illustration, Figure 22. Change Figure 22 to show the association of the abstract syntax, Classifier.feature to Feature. To: "Karl Frank" Cc: uml2-superstructure-ftf@omg.org Subject: Re: Proposed Classes issue resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 23 Feb 2004 14:17:37 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/23/2004 14:17:40, Serialize complete at 02/23/2004 14:17:40 I tend to agree with this proposed resolution in principle, but here are some things to consider first: The reason that this is association is not in figure 22 is because the corresponding concept, Property, is defined in a different diagram (which is a consequence of the fine-grained packaging of Abstractions and how Property is introduced there). To do as you suggest in your resolution would also require the introduction of Property into figure 22, moving at least some parts of its text definition from section 7.11 where it currently sits into section 7.8, and making a few editing fixes to figure 30 (removing that association and probably a few others emanating from Property). The reason that we have to do this is that we need to conform to the current organizing principles used for this chapter in which things are organized by diagram rather than by package. This unfortunate organization by diagram type -- which is explicitly described on page 26 -- is a consequence of the fine-grain structure of Abstractions. Of course, once we have done this, we have broken the homomorphism that currently exists between Infastructure packaging and the corresponding Superstructure diagrams shown in chapter 7. This unfortunate dilemma would disappear altogether if we changed the organization of the document into a consistent "by package" style as opposed to "by diagram" -- as is currently proposed in the resolution directions we are voting on currently (please vote if you have an opinion!). It is up to you, but I would recommend waiting until we have a clearer view about what we will do with this part of the spec. On a separate note: when proposing resolutions like this, it is important to follow through and list the full ramifications of a proposed solution. Thus, had we accepted your proposal in the current "reduced" form (without the additional changes in item 1 above), we would have introduced a consistency problem. So, please take care that your proposed resolutions are complete. Cheers, Bran "Karl Frank" 02/23/2004 09:14 AM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject Proposed Classes issue resolution All: please consider this issue resolution for the next ballot. - Karl and Joaquin OMG Issue No: 6158 Title: Notation for attributes Summary: The notation for attributes is given in Kernel::Classifier, but the abstract syntax for classifiers have no features. Discussion: Overview: The problem can be restated as The notation is given without a supporting diagram to show the abstract syntax of the modeling concept. The issue is correct in that Figure 22 currently omits the association with role attribute. The resolution is to add the association to Figure 22. Detailed Discussion Attribute is not a first class concept in UML 2, which is to say it is not specified using a class in the metamodel; instead it is specified using a role. The text at 7.8.1 Kernel::Classifier specifies that Classifier has an association, Classifier.attribute to Property. The properties in this role are the attributes of the classifier. The abstract syntax for Classifier does have attributes. Thus the notation is in the right place. This association (Classifier.attribute to Property) should be shown in the illustration, Figure 22. Change Figure 22 to show the association of the abstract syntax, Classifier.attribute to Property. The abstract syntax at 7.8.1 Kernel::Classifier specifies that Classifier has an association, Classifier.feature to Feature. The abstract syntax for Classifier does have features. This association is not shown in the illustration, Figure 22. Change Figure 22 to show the association of the abstract syntax, Classifier.feature to Feature. Disposition: Resolved Reply-To: From: "Conrad Bock" To: Subject: RE: Proposed Classes issue resolution Date: Mon, 23 Feb 2004 14:26:57 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i1NJQZre010326 Hi Karl, > The problem can be restated as The notation is given > without a supporting diagram to show the abstract syntax of the > modeling concept. > > The issue is correct in that Figure 22 currently omits the > association with role attribute. The resolution is to add the > association to Figure 22. Seems like we should move the text to where the abstract syntax is in this case. Attributes belong in Classes rather than Classifiers. In the Classifier class, the discussion of attributes (in the Association section, Notation, etc), should be moved to Classes. As to features, it is in the Features section and doesn't need to be moved to Classifiers (at least not for this issue). Conrad > Detailed Discussion > > Attribute is not a first class concept in UML 2, which is > to say it is not specified using a class in the metamodel; > instead it is specified using a role. The text at 7.8.1 > Kernel::Classifier specifies that Classifier has an association, > Classifier.attribute to Property. The properties in this role > are the attributes of the classifier. The abstract syntax for > Classifier does have attributes. Thus the notation is in the right place. > > This association (Classifier.attribute to Property) should > be shown in the illustration, Figure 22. Change Figure 22 to > show the association of the abstract syntax, > Classifier.attribute to Property. > > The abstract syntax at 7.8.1 Kernel::Classifier specifies > that Classifier has an association, Classifier.feature to > Feature. The abstract syntax for Classifier does have features. > > This association is not shown in the illustration, Figure > 22. Change Figure 22 to show the association of the abstract > syntax, Classifier.feature to Feature. > > Disposition: Resolved > > Subject: RE: Proposed Classes issue resolution Date: Tue, 24 Feb 2004 09:04:30 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Classes issue resolution Thread-Index: AcP60kdJiHtY5lJESousNVFsc/c6tQACaEBO From: "Karl Frank" To: "Branislav Selic" Cc: , X-OriginalArrivalTime: 24 Feb 2004 14:04:49.0186 (UTC) FILETIME=[2A5C7820:01C3FADF] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i1OE4Zre018303 Answers are in the text below, but in summary, we either have to a) show the relatiionship with role Attribute in Figure 22 or we have to b) move the notation for Attribute to 7.11. If the opinion of the group is that resolution b) is easier, we will change the writeup. Background reasons for our proposing a) are that UML 2 is raising the status of Classifier relative to Class, and indeed documents the relationship of Classifier to Property in the section on Classifier, where the Issue was reported. So it appears likely that the ommission of the relationship to Property was omitted from Figure 22 in the Classifier section and retained in 7.11 on Class, because of persistence of the old-think assumption that it was all about Class. We were proposing that the role of Property relative to Classifier should be shown with a notation where the text first brings it up. - Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tue 2/24/2004 7:31 AM To: Karl Frank Cc: conrad.bock@nist.gov; uml2-superstructure-ftf@omg.org Subject: RE: Proposed Classes issue resolution Karl and Joaquin, "Karl Frank" wrote on 02/23/2004 07:42:11 PM: > Abstract syntax, in the true sense, is not identical with the > diagramatic representation thereof, although the customary UML usage > is to equate the two. It is more than just custom and style. We use the metamodel that is shown in the figures to generate the normative XMI. > In fact, it is a pervasive defect of our spec format that there are > two competing presentations of the abstract syntax, one in the form > of the text sections and another in the form of the diagram. > Whenever one has two independent presentations, one introduces risk > of inconsistency, which is a bad design for a normative doc. This is a problem with any type of documentation. I really see no practical way of avoiding it. It could be avoided by stating which view, diagram or text, is normative, and which is a gloss to assist understanding the normative one. But this is not the issue, I only mentioned it because we are dealing with a case in which the diagram view was missing something the text view includes, namely a relationship to property which should be shown with the rolename Attribute. The spec is the documentation that accompanies the XMI. I am not sure it helps to complain about it. Of course, it would be a lot simpler if we did not split the documentation up by diagram type. > But that is another issue. In this case, the text portion already > does mention the item for which the notation is shown. Yes. But, I was pointing out that your proposed resolution is, to say the least, inconsistent. Right now, Property is described in section 7.11 not in section 7.8 and does not even appear in the diagram in figure 22. Do you want to move Property into figure 22? The proposed resolution said to add the relationship to property with role attribute to Figure 22 because the problem is that it is missing now. So the answer is yes. If so, do you want to also leave it in figure 30? The reported issue does not report any defect in figure 30, and the proposed resolution does not mention figure 30, likewise it does not mention figures 1, 2, 3, 4, 5, nor 31 nor 66. Therefore it does not request any change to those figures. If so, do you want to split the definition of Property so that some of it is in section 7.8 and the rest in 7.11? The proposed resolution does not ask for the definition of Property to be split. The reported issue concerned the notation for Attribute being shown when the role was not shown in the Figure. It may be a defect that Property is shown and discussed in multiple places. The dispersed discussion of Property is a new issue that is not mentioned in 6158. Indeed the word "property" does not even appear in the text of the issue. If so, which parts go where? I just spent a full weekend doing the updates to the text from ballots 5, 6, and 7. It turned out that a number of the "resolutions" that we voted on were incomplete in this way, making it difficult for me to enter the fixes as suggested in the text. All I am asking for is a comprehensive and complete resolution of the problem. Bran To: "Karl Frank" Cc: conrad.bock@nist.gov, uml2-superstructure-ftf@omg.org Subject: RE: Proposed Classes issue resolution X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 24 Feb 2004 09:19:43 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/24/2004 09:19:44, Serialize complete at 02/24/2004 09:19:44 ...and, of course, if we reorganize this part of the document according to the recent proposal, this would be automatically fixed along with other similar problems. BTW, I notice that Borland has not voiced its opinion in the straw poll. Cheers, Bran "Karl Frank" 02/24/2004 09:04 AM To Branislav Selic/Ottawa/IBM@IBMCA cc , Subject RE: Proposed Classes issue resolution Answers are in the text below, but in summary, we either have to a) show the relatiionship with role Attribute in Figure 22 or we have to b) move the notation for Attribute to 7.11. If the opinion of the group is that resolution b) is easier, we will change the writeup. Background reasons for our proposing a) are that UML 2 is raising the status of Classifier relative to Class, and indeed documents the relationship of Classifier to Property in the section on Classifier, where the Issue was reported. So it appears likely that the ommission of the relationship to Property was omitted from Figure 22 in the Classifier section and retained in 7.11 on Class, because of persistence of the old-think assumption that it was all about Class. We were proposing that the role of Property relative to Classifier should be shown with a notation where the text first brings it up. - Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tue 2/24/2004 7:31 AM To: Karl Frank Cc: conrad.bock@nist.gov; uml2-superstructure-ftf@omg.org Subject: RE: Proposed Classes issue resolution Karl and Joaquin, "Karl Frank" wrote on 02/23/2004 07:42:11 PM: > Abstract syntax, in the true sense, is not identical with the > diagramatic representation thereof, although the customary UML usage > is to equate the two. It is more than just custom and style. We use the metamodel that is shown in the figures to generate the normative XMI. > In fact, it is a pervasive defect of our spec format that there are > two competing presentations of the abstract syntax, one in the form > of the text sections and another in the form of the diagram. > Whenever one has two independent presentations, one introduces risk > of inconsistency, which is a bad design for a normative doc. This is a problem with any type of documentation. I really see no practical way of avoiding it. It could be avoided by stating which view, diagram or text, is normative, and which is a gloss to assist understanding the normative one. But this is not the issue, I only mentioned it because we are dealing with a case in which the diagram view was missing something the text view includes, namely a relationship to property which should be shown with the rolename Attribute. The spec is the documentation that accompanies the XMI. I am not sure it helps to complain about it. Of course, it would be a lot simpler if we did not split the documentation up by diagram type. > But that is another issue. In this case, the text portion already > does mention the item for which the notation is shown. Yes. But, I was pointing out that your proposed resolution is, to say the least, inconsistent. Right now, Property is described in section 7.11 not in section 7.8 and does not even appear in the diagram in figure 22. Do you want to move Property into figure 22? The proposed resolution said to add the relationship to property with role attribute to Figure 22 because the problem is that it is missing now. So the answer is yes. If so, do you want to also leave it in figure 30? The reported issue does not report any defect in figure 30, and the proposed resolution does not mention figure 30, likewise it does not mention figures 1, 2, 3, 4, 5, nor 31 nor 66. Therefore it does not request any change to those figures. If so, do you want to split the definition of Property so that some of it is in section 7.8 and the rest in 7.11? The proposed resolution does not ask for the definition of Property to be split. The reported issue concerned the notation for Attribute being shown when the role was not shown in the Figure. It may be a defect that Property is shown and discussed in multiple places. The dispersed discussion of Property is a new issue that is not mentioned in 6158. Indeed the word "property" does not even appear in the text of the issue. If so, which parts go where? I just spent a full weekend doing the updates to the text from ballots 5, 6, and 7. It turned out that a number of the "resolutions" that we voted on were incomplete in this way, making it difficult for me to enter the fixes as suggested in the text. All I am asking for is a comprehensive and complete resolution of the problem. Bran Subject: Proposed Classifier Attribute resolutions for Ballot 18 Date: Tue, 6 Jul 2004 09:29:05 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed Classifier Attribute resolutions for Ballot 18 Thread-Index: AcRhYEpFYuDWFJC3TZWPyef6e5HUtQCFQSVw From: "Karl Frank" To: "Branislav Selic" , , X-OriginalArrivalTime: 06 Jul 2004 16:29:23.0262 (UTC) FILETIME=[65742DE0:01C46376] The two issues addressed in the attached are VERY BIG ISSUES and need the attention of other eyes. A difficulty in deciding whether the proposed resolution will cause problems is that there is no indication in the superstructure FAS as to WHY someone changed the metamodel of the Infrastructure, wrt attributes, so there is no record of what problem will be caused by fixing an inconsistency by reverting back to the infrastructure metamodel. There are 646 usages of "attribute" in the Superstructure FAS and I have exhausted my patience in trying to read them all, in an attempt to see what new problems the proposed resolution may cause. - Karl Issues_6156_6158_for_ballot18.doc OMG Issue No: 6158 Title: Notation for attributes Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The notation for attributes is given in Kernel::Classifier, but the abstract syntax for classifiers have no features Discussion: The resolution for 6156 moves the notation attributes out of the Kernel:Classifier section, so the absence of attributes from the abstract syntax diagram is no longer an issue. Disposition: Duplicate To: "Karl Frank" Cc: "Branislav Selic" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: Proposed Classifier Attribute resolutions for Ballot 18 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Tue, 6 Jul 2004 13:51:04 -0400 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/06/2004 13:50:47, Serialize complete at 07/06/2004 13:50:47 Karl, Please note that Class is not the only metaclass that defines a property (i.e. ownedAttribute) that subsets Classifier::attribute; the others are Artifact, Collaboration, DataType, Interface, Signal, and StructuredClassifier. Indeed, it seems to me that the general concept of attributes was intended to apply not only to classes, but to other classifiers in Superstructure, so I'm not sure it's safe to remove the Classifier::attribute derived union after all... Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Karl Frank" 07/06/2004 12:29 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject Proposed Classifier Attribute resolutions for Ballot 18 The two issues addressed in the attached are VERY BIG ISSUES and need the attention of other eyes. A difficulty in deciding whether the proposed resolution will cause problems is that there is no indication in the superstructure FAS as to WHY someone changed the metamodel of the Infrastructure, wrt attributes, so there is no record of what problem will be caused by fixing an inconsistency by reverting back to the infrastructure metamodel. There are 646 usages of "attribute" in the Superstructure FAS and I have exhausted my patience in trying to read them all, in an attempt to see what new problems the proposed resolution may cause. - Karl[attachment "Issues_6156_6158_for_ballot18.doc" deleted by Kenneth Hussey/Ottawa/IBM] Subject: RE: Proposed Classifier Attribute resolutions for Ballot 18 Date: Tue, 6 Jul 2004 10:58:27 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Classifier Attribute resolutions for Ballot 18 Thread-Index: AcRjgYK6lSEjpMtXT8ubsftozbDPtgAAJ0xg From: "Karl Frank" To: "Kenneth Hussey" Cc: "Branislav Selic" , , X-OriginalArrivalTime: 06 Jul 2004 17:58:34.0850 (UTC) FILETIME=[DB3FB420:01C46382] Thanks Ken, then should we 1. promote the ownedAttribute composition up the inheritance hierarchy to Classifier? so it is merely inherited by Class? 2. remove the text from the Class section which DEFINES class as a classifier that has Attributes 3. what about the notation section which now appears only in the Classifier section (and yet only has examples of CLASSES!) - Karl -------------------------------------------------------------------------------- From: Kenneth Hussey [mailto:khussey@ca.ibm.com] Sent: Tuesday, 06 July, 2004 1:51 PM To: Karl Frank Cc: Branislav Selic; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: Proposed Classifier Attribute resolutions for Ballot 18 Karl, Please note that Class is not the only metaclass that defines a property (i.e. ownedAttribute) that subsets Classifier::attribute; the others are Artifact, Collaboration, DataType, Interface, Signal, and StructuredClassifier. Indeed, it seems to me that the general concept of attributes was intended to apply not only to classes, but to other classifiers in Superstructure, so I'm not sure it's safe to remove the Classifier::attribute derived union after all... Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Karl Frank" 07/06/2004 12:29 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject Proposed Classifier Attribute resolutions for Ballot 18 The two issues addressed in the attached are VERY BIG ISSUES and need the attention of other eyes. A difficulty in deciding whether the proposed resolution will cause problems is that there is no indication in the superstructure FAS as to WHY someone changed the metamodel of the Infrastructure, wrt attributes, so there is no record of what problem will be caused by fixing an inconsistency by reverting back to the infrastructure metamodel. There are 646 usages of "attribute" in the Superstructure FAS and I have exhausted my patience in trying to read them all, in an attempt to see what new problems the proposed resolution may cause. - Karl[attachment "Issues_6156_6158_for_ballot18.doc" deleted by Kenneth Hussey/Ottawa/IBM] To: "Karl Frank" Cc: "Branislav Selic" , "Kenneth Hussey" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Proposed Classifier Attribute resolutions for Ballot 18 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 6 Jul 2004 14:31:37 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF262 | May 19, 2004) at 07/06/2004 12:31:39, Serialize complete at 07/06/2004 12:31:39 See below. "Karl Frank" 07/06/2004 01:58 PM To "Kenneth Hussey" cc "Branislav Selic" , , Subject RE: Proposed Classifier Attribute resolutions for Ballot 18 Thanks Ken, then should we 1. promote the ownedAttribute composition up the inheritance hierarchy to Classifier? so it is merely inherited by Class? no because it already subsets derived union Classifier::attribute. What's missing is Class::ownedAttribute (and perhaps other "attributes" needs to subset Classivier::feature too? 2. remove the text from the Class section which DEFINES class as a classifier that has Attributes This is using the more specific idea of attribute, something that defines an identifiable characteristic of a class that is included in its state. The class actually has Properties which are contributed to the Classifier::attribute derived union. Other metaclasses may have a different idea about what its attributes mean. 3. what about the notation section which now appears only in the Classifier section (and yet only has examples of CLASSES!) Examples of other "attributes" are included in their specific sections. It wouldn't hurt to add another example in the Classifier section just to indicate there are other kinds of attributes contributed by other metaclasses. - Karl -------------------------------------------------------------------------------- From: Kenneth Hussey [mailto:khussey@ca.ibm.com] Sent: Tuesday, 06 July, 2004 1:51 PM To: Karl Frank Cc: Branislav Selic; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: Proposed Classifier Attribute resolutions for Ballot 18 Karl, Please note that Class is not the only metaclass that defines a property (i.e. ownedAttribute) that subsets Classifier::attribute; the others are Artifact, Collaboration, DataType, Interface, Signal, and StructuredClassifier. Indeed, it seems to me that the general concept of attributes was intended to apply not only to classes, but to other classifiers in Superstructure, so I'm not sure it's safe to remove the Classifier::attribute derived union after all... Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "Karl Frank" 07/06/2004 12:29 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject Proposed Classifier Attribute resolutions for Ballot 18 The two issues addressed in the attached are VERY BIG ISSUES and need the attention of other eyes. A difficulty in deciding whether the proposed resolution will cause problems is that there is no indication in the superstructure FAS as to WHY someone changed the metamodel of the Infrastructure, wrt attributes, so there is no record of what problem will be caused by fixing an inconsistency by reverting back to the infrastructure metamodel. There are 646 usages of "attribute" in the Superstructure FAS and I have exhausted my patience in trying to read them all, in an attempt to see what new problems the proposed resolution may cause. - Karl[attachment "Issues_6156_6158_for_ballot18.doc" deleted by Kenneth Hussey/Ottawa/IBM] Subject: RE: Proposed Classifier Attribute resolutions for Ballot 18 Date: Wed, 7 Jul 2004 11:48:19 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed Classifier Attribute resolutions for Ballot 18 Thread-Index: AcRjgYK6lSEjpMtXT8ubsftozbDPtgA0JaKQ From: "Karl Frank" To: "Kenneth Hussey" , "Jim Amsden" , "Branislav Selic" , "Conrad Bock" Cc: X-OriginalArrivalTime: 07 Jul 2004 18:48:33.0940 (UTC) FILETIME=[01424540:01C46453] With the help of Ken, Jim, and Conrad, what I thought was a big issue has become a very simple no-brainer. Please see the attached doc with two proposed resolutions. - Karl OMG Issue No: 6158 Title: Notation for attributes Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The notation for attributes is given in Kernel::Classifier, but the abstract syntax for classifiers have no features Discussion: The abstract syntax for classifiers does have attributes, subsetting features, as is made clear in the resolution to 6156. This issue was submitted when the syntax diagram for classifier did not show /attribute, a defect fixed by the resolution to 6156. Disposition: Resolved, no change. Reply-To: From: "Desfray" To: "'Karl Frank'" , "'Kenneth Hussey'" , "'Jim Amsden'" , "'Branislav Selic'" , "'Conrad Bock'" Cc: Subject: RE: Proposed Classifier Attribute resolutions for Ballot 18 Date: Thu, 8 Jul 2004 13:21:00 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A8A42AB300 For whose who where wondering "to whom the hell can belong a property or feature, else than a classifier", I beleive that the answer may be : PROPERTY (look at property) * qualifier : Property [*] An optional list of ordered qualifier attributes for the end. If the list is empty, then the Association is not qualified. Subsets Element::ownedElement. So a property can own a property which will be a qualifier. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysees 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Karl Frank [mailto:Karl.Frank@borland.com] Envoye : mercredi 7 juillet 2004 20:48 A : Kenneth Hussey; Jim Amsden; Branislav Selic; Conrad Bock Cc : uml2-superstructure-ftf@omg.org Objet : RE: Proposed Classifier Attribute resolutions for Ballot 18 With the help of Ken, Jim, and Conrad, what I thought was a big issue has become a very simple no-brainer. Please see the attached doc with two proposed resolutions. - Karl abstract syntax for classifiers have no features.