Issue 1084:  Single-valued parameters should not be defined with sequences (mof-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: If attributes with a datatype as their type are constrained
 in the Model to disallow the cardinality of [0..1], as
 recommended in a separate issue, then the handling of
 parameters with cardinality defined as [0..1] can be
 simplified, as compared to the recommendation in issue #940.
 
 This constraint allows parameters with cardinality to be
 treated as optional, single-valued parameters, instead of as
 sets.  The difference for clients and implementations is
 significant. 
 

Resolution: closed issue
Revised Text: 
Actions taken:
March 18, 1998: received issue
July 23, 1999: closed issue
Discussion: 
Response: The current specification treats 0..1 cardinalities as the special "optional" case
for Attributes, but does not do so for Parameters. Currently, 0..1 cardinality Parameters
are treated as 0..N cardinality Parameters (i.e. as sequences). We don't believe the current
specification is broken. We agree that working with such parameters as sequences might
be inconvenient and we wouldn't encourage people to define metamodels using optional
parameters (since CORBA has no direct support for optional parameters), but we see no
reason to actually disallow it if people are determined to do it.
The alternative would be to define 0..1 cardinality Parameters as unions (one branch with-out a value and one branch with the value). This is intellectually cleaner, but working with
the implementation of unions is probably as inconvenient as working with the implementa-tion
of sequences.
All in all, it ain't broken, so don't fix it.
The issue of whether this is really an issue is still an issue :-)
Proposed resolution - close with no action.
Implementation: Nothing to do. Done [KR].
End of Annotations:=====
Return-Path: <GK.Khalsa@unisys.com>
From: "Khalsa, GK" <GK.Khalsa@unisys.com>
To: issues@omg.org, mof-rtf@omg.org
Subject: MOF-RTF: single-valued parameters should not be defined with
sequ
	ences
Date: Wed, 18 Mar 1998 12:39:23 -0600

If attributes with a datatype as their type are constrained
in the Model to disallow the cardinality of [0..1], as
recommended in a separate issue, then the handling of
parameters with cardinality defined as [0..1] can be
simplified, as compared to the recommendation in issue #940.

This constraint allows parameters with cardinality to be
treated as optional, single-valued parameters, instead of as
sets.  The difference for clients and implementations is
significant.  Consider this operation:

operation
---------
name: availableResource

parameter
---------
name: kind
type: string
direction: in
multiplicity: [1..1]

parameter
---------
name: preferredProvider
annotation: when not supplied, no preference is considered
type: Source
direction: in
multiplicity: [0..1]

parameter
---------
name: **return**
type: Resource
direction: return
multiplicity: [0..1]

Under the approach recommended by issue #940, the IDL would
be:


  ResourceSet available_resource(in string kind,
                                 in SourceSet preferred_provider);

Under the approach above, it can be:

  Resource available_resource(in string kind,
                              in Source preferred_provider);

The second is the more intuitive and usable operation.  The
CORBA Services have many operations with parameters which
accept nil object references, and many operations which
return nil object references.  None define the parameter or
return type as a sequence.

Also, OCL takes this approach (Section 5.4, page 8):
  "If the multiplicity of the association-end has a maximum
  of one ("0..1" or "1"), then the value of this expression
  is an object. 

The OCL specification defines navigation through
association-ends (to support UML); but the MOF also used OCL
navigating through references.