Issues for Mailing list of the UML Profile and Metamodel for Services (SoaML) Finalization Task Force

To comment on any of these issues, send email to soaml-ftf@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 14922: Title: Figure 95 uses instance keyword instead of part
Issue 14923: Figure 95 extends activity execution semantics
Issue 14924: Figure 95 uses UML ports without UML semantics

Issue 14922: Title: Figure 95 uses instance keyword instead of part (soaml-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary:
Figure 95 uses instance keyword, which isn't defined in UML.  The
  figure isn't explained well, but perhaps it could use the part
  keyword, or extend UML with a port keyword

Resolution:
Revised Text:
Actions taken:
January 6, 2010: received issue

Issue 14923: Figure 95 extends activity execution semantics (soaml-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Figure 95 isn't explained very well, but from other conversations it
  seems to assume the runtime target of invocation actions can be derived
  from the the partition.  While port/part partitions require the target
  input of invocation actions to be the runtime value of a specific
  property represented by the partition, they do not have the execution
  semantics to assign the value.  This could be described in soaML as an
  extension of UML semantics.  Probably affected by next issue.

Resolution:
Revised Text:
Actions taken:
January 6, 2010: received issue

Issue 14924: Figure 95 uses UML ports without UML semantics (soaml-ftf)

Click
here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:
Figure 95 isn't explained very well, but from other conversations it
  seems to assume partitions representing ports have (references to)
  external objects as runtime values, where the external objects are the
  ones at the other end of the connector coming into the port from
  outside.  This is assumed so the invocation actions can send these
  external objects operation calls based on the partitions they are in (
  the partitions represent port properties, which means the runtime value
  of the ports must be the runtime input values of invocation actions in
  the partition).


  However, ports are composite properties, see constraint [2] on ports,
  which means external objects that are values of ports would be deleted
  with when the runtime owner of the port is.  For example, deleting a
  buyer object would delete the seller object at runtime.  In addition,
  it would be a very rare user of UML that would assume an externally
  connected port connector had as its value the object at the other end
  of the connector.  This is very far from UML, with significant
  unintended consequences.


  soaML could define an extension of UML for port partitions to give the
  semantics of InvocationAction:onPort with input pin targeting "self".
  Then the operation calls would go through the port represented by the
  partition to the external object.

Resolution:
Revised Text:
Actions taken:
January 6, 2010: received issue