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 9603: Section: 1.2.x (CorbaToWsdl)
Issue 12983: Section 5.8: What is the value of the definition of "OtherSyntaxObject"?
Issue 12984: Section: Section 3.1.9, Figure 41
Issue 13645: Exchanges should be extended to allow Software and CapabilityConfigurations to be conveyed as well.
Issue 13646: All of the derived tags require the derivation documenting.
Issue 15227: There are no services defined to capture or modify case files

Issue 9603: Section: 1.2.x (CorbaToWsdl) ()

Nature:
Severity:
Summary:

Resolution: duplicate of issue # 9602
Revised Text:
Actions taken:

Issue 12983: Section 5.8: What is the value of the definition of "OtherSyntaxObject"? ()

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Clarification
Severity: Minor
Summary:

Section 5.8: What is the value of the definition of "OtherSyntaxObject"?

Resolution: The change to specification is to replace name OtherSyntaxObject with new name MinorSyntaxObject at following places: Table 2.3, page# <40>; Section# <2.11>, page# <47>, line# <14>; Section# <2.11.1>, page# <47>, line# <18>; Section# <3.1.6>, page# <63>, line# <13>; Section# <3.2.1.3>, page# <82>, line# <24>; Section# <3.2.1.3>, page# <83>, line# <1>; Section# <3.2.1.5>, page# <105>, line# <33, 35>; Section# <3.2.1.5.9.3>, page# <113>, line# <2, 23>; Section# <3.2.1.5.9.5>, page# <114>, line# <8>; Section# <3.2.1.5.9.6>, page# <115>, line# <9>; Section# <3.2.1.5.9.7>, page# <115>, line# <23>; Section# <A.2.1>, page# <123>, line# <4>. An equivalent change is recommended in Figures 17, 21, 23, 33, , page# <65>as follows (only Figure 33 is shown since all other diagrams are already shown in previous issues of Ballot 2) Figure 35 Disposition: Resolved
Revised Text:
Actions taken:
October 22, 2008: received issue
January 12, 2010: received issue

Discussion:

It is an abstract parent class for a large number of minor classes that would otherwise be direct children of SyntaxObject.  We can consider renaming it, possibly: MinorSyntaxObjects.

Issue 12984: Section: Section 3.1.9, Figure 41 ()

Click here for this issue's archive.
Source: TCS (Mr. Ravindra Naik, rd.naik(at)tcs.com)
Nature: Clarification
Severity: Minor
Summary:

From consistency point of view, suggest change name of association "aName" between "LabelAccess" and "Name" to "labelName". Also association "aDefinition" between "LabelAccess" and "LabelDefinition" to "labelDefinition".

Resolution: A change to specification will be in section# <2.11.2>, page# 50, line# 1 will change name of association from "name" to "typeName". The Figure 20, in section# <3.1.6>, page# <65> will incorporate an appropriate equivalent change as follows. Figure 20 A change to specification will be in section# <3.2.1.3.3.3>, page# 89, line# 2 will change name of association from "name" to "typeName". A change to specification will be in section# <2.11.5>, page# 53, line# 8 will change name of association from "name" to "typeName". The Figure 27, in section# <3.1.7>, page# <70> will incorporate an appropriate equivalent change as follows. Figure 26 A change to specification will be in section# <3.2.1.3.4.5.2>, page# 96, line# 15 will change name of association from "name" to "typeName". A change to specification will be in section# <2.11.7>, page# 55, line# 45 will change name of association from "name" to "identifierName". The Figure 39, in section# <3.1.9>, page# <78> will incorporate an appropriate equivalent change as follows: Figure 41 A change to specification will be in section# <3.2.1.4.9>, page# 100, line# 5 will change name of association from "name" to "identifierName". A change to specification will be in section# <2.11.7>, page# 58, line# 13 will change name of association from "name" to "labelName". The Figure 41, in section# <3.1.9>, page# <79> will incorporate an appropriate equivalent change as follows. Figure 43 A change to specification will be in section# <3.2.1.4.11>, page# 101, line# 28 will change name of association from "name" to "labelName". A change to specification will be in section# <2.11.7>, page# 58, line# 14 will change name of association from "definition" to "labelDefinition". The Figure 41, in section# <3.1.9>, page# <79> will incorporate an appropriate equivalent change as above. A change to specification will be in section# <3.2.1.4.11>, page# 101, line# 29 will change name of association from "definition" to "labelDefinition". The Figure 28, in section# <3.1.7>, page# <71> will incorporate change to replace association name "aType" with "type" between objects NamedTypeReference and TypeDefinition, and association name "aType" with "type" between objects UnnamedTypeReference and Type, and is yet to be created. Figure 26 Disposition: Resolved
Revised Text:
Actions taken:
October 23, 2008: received issue
January 12, 2010: closed issue

Discussion:

The names of associations mentioned in the summary are somewhat different in the Beta1 release of the specification document. However, they still need to be made uniform. In addition to the above association names, there are few more associations whose names need to be made uniform. These are:
·	Association name between objects TypeDefinition and Name
·	Association name between objects NamedTypeReference and Name
·	Association name between objects NameReference and Name
·	Association name between objects LabelAccess and Name
·	Association definition between objects LabelAccess and LabelDefinition
Some of the associations have inconsistent names in the specifications and the diagrams. They are:
·	Association names "aType" between objects NamedTypeReference and TypeDefinition, and "aType" between objects UnnamedTypeReference and Type, in the diagrams

Issue 13645: Exchanges should be extended to allow Software and CapabilityConfigurations to be conveyed as well. ()

Click here for this issue's archive.
Source: Atego (Mr. Phillip Astle, phil.astle(at)atego.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Exchanges should be extended to allow Software and CapabilityConfigurations to be conveyed as well.	
Diagram 	 OV-2 / SV-1
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Phillip AstleArtisan Software Toolsphillip.astle@artisansoftwaretools.com

Rationale	 You cannot fully model the logistics of an architecture currently.
Resolution	 TBD. Needs discussion

Resolution: MaterialExchange will be updated to allow Software and ResourceArtifacts to be attached in the "conveyed" role. A new stereotype, called "ConfigurationExchange" will be added as a specialization of OperationalExchange, with it's "conveyed" role linked to CapabilityConfiguration. This new stereotype will be displayed in all the places that the other OperationalExchanges are. The description for ConfigurationExchange will be: "CapabilityConfigurations that are exchanged between Nodes".
Revised Text: see dtc/2009-06-11 for more details
Actions taken:
February 27, 2009: received issue
October 20, 2009: closed issue

Issue 13646: All of the derived tags require the derivation documenting. ()

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

All of the derived tags require the derivation documenting.	
Diagram 	 OV-5 + others
Document Issue	UPDM (OMG Beta) Jan 2009

Source	 Andrius StrazdauskasNo Magicandriuss@nomagic.com

Rationale	 Currently the implementation isn't complete without it.
Resolution: We'll add, as a minimum, a detailed description in English but if possible we will also include OCL.

Resolution: Add derivation rules next to attributes description
Revised Text: Needline.exchangedItem A list of OperationalExchanges that are realized by the Needline. This is derived by doing the inverse of the UML "realizingConnector" and "realization" roles, that are owned by InformationFlow. OperationalElement.implementedBy A list of SystemElements that implement the OperationalElement via the ImplementsOperational relationship. This is derived as follows: · OperationalElement to ImplementsOperational via the "supplierDependency" role. · ImplementsOperational to SystemElement via the "client" role. OperationalExchange.consumingActivity A list of OperationalActivities that consume an OperationalExchange via OperationalActivityEdges and their directly/indirectly connected OperationalActivityActions. This is derived as follows: · OperationalExchange to OperationalActivityEdge via the "realizingMessage" role · OperationalActivityEdge to OperactionActivityAction via the "target" role (if the target is a pin on an OperationalActivityAction, another jump is required from the pin to the action via an inverse navigation of the action's "argument" role). · OperationalActivityAction to OperationalActivity via the "behavior" role. OperationalExchange.producingActivity A list of OperationalActivities that produce an OperationalExchange via OperationalActivityEdges and their directly/indirectly connected OperationalActivityActions. This is derived as follows: · OperationalExchange to OperationalActivityEdge via the "realizingMessage" role · OperationalActivityEdge to OperactionActivityAction via the "source" role (if the source is a pin on an OperationalActivityAction, another jump is required from the pin to the action via an inverse navigation of the action's "result" role). · OperationalActivityAction to OperationalActivity via the "behavior" role. OperationalMessage / ResourceMessage / ServiceMessage.carries A list of realized OperationalExchanges/ResourceInteractions that are realized by the message. This is derived by doing the inverse of the UML "realizingMessage" role, that are owned by InformationFlow. ResourceConnector / ResourceInterface.exchangedItem A list of ResourceInteractions that are realized by the ResourceConnector/ResourceInterface. This is derived by doing the inverse of the UML "realizingConnector" and "realization" roles, that are owned by InformationFlow. ResourceInteraction.consumingFunction A list of Function that consume a ResourceInteraction via FunctionEdges and their directly/indirectly connected FunctionActions. This is derived as follows: · ResourceInteraction to FunctionEdge via the "realizingMessage" role · FunctionEdge to FunctionAction via the "target" role (if the target is a pin on an FunctionAction, another jump is required from the pin to the action via an inverse navigation of the action's "argument" role). · FunctionAction to Function via the "behaviour" role. ResourceInteraction.producingFunction A list of Functions that produce an ResourceInteraction via FunctionEdges and their directly/indirectly connected FunctionActions. This is derived as follows: · ResourceInteraction to FunctionEdge via the "realizingMessage" role · FunctionEdge to FunctionAction via the "source" role (if the source is a pin on an FunctionAction, another jump is required from the pin to the action via an inverse navigation of the action's "result" role). · FunctionAction to Function via the "behavior" role. SystemsElement.implements A list of OperationalElements that are implemented by the SystemElement via the ImplementsOperational relationship. This is derived as follows: · SystemElement to ImplementsOperational via the "clientDependency" role. · ImplementsOperational to OperationalElement via the "supplier" role. ActivitySubject.actsUpon A list of all the OperationalActivities that act upon the ActivitySubject. This is the inverse of the OperationalActivity "subject" role. OperationalActivity/Function.subject A list of all the ActivitySubjects that are acted/functioned upon by the OperationalActivity/Function. The list is derived by looking at all the ObjectNodes scoped within the OperationalActivity (directly or indirectly via StructuredActivityNodes, etc) and getting a unique list of their types. ResourceInteractionItem.functionsUpon A list of all the Functions that act upon the ActivitySubject. This is the inverse of the Function "subject" role.
Actions taken:
February 27, 2009: received issue
October 20, 2009: closed issue

Issue 15227: There are no services defined to capture or modify case files ()

Click here for this issue's archive.
Source: Lockheed Martin (Mr. John Olden-Stahl, john.olden-stahl(at)lmco.com)
Nature: Uncategorized Issue
Severity:
Summary:

CaseFile is referenced in the static structure of the model; however, there are no services defined to capture or modify case files.  Has this been further defined or should we assume we develop our own services and interpretation?

Resolution: The requisite services are to be added
Revised Text: The revised text for this issue is included in that for Issue 15782, “Service packages require operation definitions”. Those definitions that have been added for this issue have been additionally tagged as such in the change-barred convenience document.
Actions taken:
April 23, 2010: received issue
April 25, 2011: closed issue