Issues for

To comment on any of these issues, send email to @omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 8184: Section: 11.3.39
Issue 12636: Must all implementations have a design-time activity?
Issue 17803: Capitalization of dependency
Issue 17885: Query of alternative scopes?
Issue 18033: Location: 17.3.4 Notation Lifeline p 613 - Specification of color

Issue 8184: Section: 11.3.39 ()

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - Add an "s" to the first classifier in Description. The multiplicities for the associations newClassifier:Classifier[0..*] and oldClassifier:Classifer[0..*] do not agree with fig. 153. Please correct either figure or text - probably figure. Semantics need to clarify the differences/similarities between "existing," "old," and "new" classifiers

Resolution:
Revised Text:
Actions taken:
January 31, 2005: received issue

Issue 12636: Must all implementations have a design-time activity? ()

Click here for this issue's archive.
Source: SWIFT (Mr. Frank Vandamme, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

Current text
In particular, an implementation needs to support a design-time activity with all of the steps involved in generating the conversion maps, and the runtime application of the generated maps to a source physical message in order to create a target physical message.
New text
SEE QUESTIONS & COMMENTS IN NEXT COLUMN
Rationale
Must all implementations have a design-time activity? Don't we expect to have more implementations that use the conversion maps than implementations that can create the maps?

Resolution:
Revised Text:
Actions taken:
July 8, 2008: received issue

Issue 17803: Capitalization of dependency ()

Click here for this issue's archive.
Source: Oracle (Mr. Dave Hawkins, dave.hawkins(at)oracle.com)
Nature: Uncategorized Issue
Severity: Minor
Summary:

"dependency" should be "Dependency"

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 17885: Query of alternative scopes? ()

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org)
Nature: Clarification
Severity: Minor
Summary:

It should be possible  within UML to query which of the alternative semantics apply.

Resolution:
Revised Text:
Actions taken:
September 26, 2012: received issue

Issue 18033: Location: 17.3.4 Notation Lifeline p 613 - Specification of color ()

Click here for this issue's archive.
Source: Lockheed Martin (Mr. Lenny Delligatti, lenny_delligatti2(at)omg.org)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Description: This clause states, “ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline.”  However, this is inconsistent with the idea that UML does not prescribe color for notations

Proposed Resolution:   In place of references to color, we should stick with the convention of using the terms “hollow” to mean the same color as the diagram background and “solid” to mean the same color as the boundary of the node or the path notation.  In the case of overlapping notations (e.g. ExecutionSpecifications), perhaps the spec. can prescribe patterns (e.g. cross-hatch) instead of color.

Source: Lenny Delligatti
Discussion:

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Discussion:

Without this, any tool that shaded these a nice pastel would be non-compliant.
Michael Jesse Chonoles