Issue 8082: Section: 13.1.5 (uml2-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: Figure 115 shows the <<enumeration>> Color, but shouldn't that be labeled as ColorKind as shown in Figure 88 and specified in Conventions and Typography in 8.5? Resolution: Revised Text: Actions taken: January 10, 2005: received issue August 23, 2006: closed issue Discussion: The example shows an example of a user model that does not have to conform to the conventions used in the spec itself. Furthermore, there is no Style Guideline associated with Enumeration that might suggest that the convention used in the spec should be applied to user models as well. Hence, this is a perfectly valid example and nothing needs to be changed. Disposition: Closed, no change End of Annotations:===== m: webmaster@omg.org Date: 10 Jan 2005 10:57:03 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jane Messenger Company: U. S. Geological Survey mailFrom: jmessenger@usgs.gov Notification: Yes Specification: Infrastructure Section: 13.1.5 FormalNumber: ptc/03-09-15 Version: 2.0 RevisionDate: 12/01/2003 Page: 173 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description Figure 115 shows the <> Color, but shouldn't that be labeled as ColorKind as shown in Figure 88 and specified in Conventions and Typography in 8.5? Reply-To: Joaquin Miller X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Apr 2005 11:15:55 -0700 To: UML-RTF From: Joaquin Miller Subject: Ballot 1 draft Please review the proposed ballot 1 resolutions. I sent out a batch yesterday and others will, presumably, send some out later today and tomorrow. If you have any problems with any of the resolutions, this is the time to raise them, not when the ballot has been issued and the vote started. Issue 6275 This would have been clearer had there been an explicit {redefines raisedException} constraint on Operations::raisedException, so let's add that. Or, let's make explicit the reasonable policy that we have limited resources, so we will fix actual errors but not work to improve usability. Issue 6616 The isLeaf feature seems unnecessary, since it is easy to determine if something is a leaf classifier simply by checking whether it is included in the .generalization. meta-attribute of any classifier. In contrast, the .isRoot. property, on the other hand is necessary since it defines a constraint that defines that a classifier must not have any further generalizations. Or is it our intention that UML 2 does not have the capability to specify that the authors of a model intend that users are not to generalize from certain classifiers? Or, perhaps, is it explicit or implicit or assumed in the UML 2 specification that users can't or won't generalize existing classifiers, but that they can and will specialize existing classifiers? Issue 8075 Our audience includes readers of paper documents. If this happens only in a few places, let's correct this usability problem. If it is our policy to cater only to readers using Acrobat or Acrobat Reader, well... Maybe it is too late to change that policy. Issue 8082 Does the proposed resolution describe a best practice? Wouldn't the spec shine even more brightly if it stuck to a single style, even in examples? This is a pedagogical question, and very much worth our time to consider. Issues 8081, 8085, and 6502 I don't want to make work, but do have a question: Is there a positive reason to use integer instead of unlimited natural in the specification of lower bound, and then backpedal with a constraint? (I bet there is a positive reason not to use unlimited natural, and a good one; but then let's mention that reason in the resolution. If we had more resources, i'd urge adding natural to our armamentarium. ) Cordially, Joaquin www.joaquin.net