Issue 8944: Enumerated SatisfierProperties                                                                                                                                                                          (deployment-rtf)
Source: Mercury Computer Systems (Mr. Frank Pilhofer, fpilhofe@mc.com)
Nature: Uncategorized Issue
Severity: 
Summary: Section 9.3.5, "SatisfierProperty," defines the concrete
data types that a SatisfierProperty's value can assume,
depending on the SatisfierPropertyKind.


For the "Attribute" kind, it allows the value to be of a
(user-defined) enumeration type. It then says, "if the value
of the SatisfierProperty is of enumeration type, the value
of the Property is of type string, containing the enumeration
value that must compare equal to the SatisfierProperty value.


This is straightforward enough. E.g., it allows a
DomainAdministrator to enumerate the kinds of processors
in a domain,


  enum Processors { ix86, ppc, sparc };


and then to tag each node with a resource containing a
property of this type, its value specifying the actual
processor type of the node.


It seemed like a good idea. Yet this feature does not buy
much. The DomainAdministrator could just as well use an
attribute of type string to the same effect. The only
advantage is that the enumerated property allows the
DomainAdministrator to constrain the values that a
SatisfierProperty may have. But it's the DomainAdmininstrator
constraining himself, so it's not much of a constraint.


However, this feature does add a dependency on DynamicAny
for both the TargetManager and the Planner, which do not
know about any user-defined enumeration types. All the other
SatisfierPropertyKind options use basic IDL data types (long,
unsigned long, double or string).


So, because of the added complexity, and the low mileage, I
propose to remove enumerated properties from the spec.


Proposed resolution:


In section 9.3.5, "SatisfierProperty," change the fourth
and fifth bullet from:


    For the Attribute kind, the value of the SatisfierProperty
    is of type long, double, string, or an enumeration type.
    In the case of long, double or string, the value of the
    Property must be of the same type. If the value of the
    SatisfierProperty is of enumeration type, the value of
    the Property is of type string, containing the enumeration
    value that must compare equal to the SatisfierProperty
    value.


    For the Selection kind, the value of the SatisfierProperty
    is a sequence of type long, double, string, or an
    enumeration type. The same rules as for the Attribute kind
    apply.


To:


    For the Attribute kind, the value of the SatisfierProperty
    is of type long, double or string. The value of the
    Property must be of the same type and compare equal to
    the SatisfierProperty value.


    For the Selection kind, the value of the SatisfierProperty
    is a sequence of type long, double or string. The same
    rules as for the Attribute kind apply.
Resolution: 
Revised Text: In section 9.3.5, "SatisfierProperty," change the fourth and fifth bullet from:

    For the Attribute kind, the value of the 
    SatisfierProperty is of type long, double, string, or 
    an enumeration type.
    In the case of long, double or string, the value of the
    Property must be of the same type. If the value of the
    SatisfierProperty is of enumeration type, the value of
    the Property is of type string, containing the 
    enumeration value that must compare equal to the 
    SatisfierProperty value.

    For the Selection kind, the value of the 
    SatisfierProperty is a sequence of type long, double, 
    string, or an enumeration type. The same rules as for 
    the Attribute kind apply.

To:

    For the Attribute kind, the value of the 
    SatisfierProperty is of type long, double or string. 
    The value of the Property must be of the same type and 
    compare equal to the SatisfierProperty value.

    For the Selection kind, the value of the 
    SatisfierProperty is a sequence of type long, double or 
    string. The same rules as for the Attribute kind apply.


Disposition:	Resolved

Actions taken:
August 1, 2005: received issue
June 7, 2006: closed issue
Discussion: 
Resolution:
Because of the added complexity, and the low mileage, I propose to remove enumerated properties from the spec. 

End of Annotations:=====
ubject: Enumerated SatisfierProperties 
Date: Mon, 1 Aug 2005 13:22:22 -0400 
Thread-Topic: Enumerated SatisfierProperties 
Thread-Index: AcWWvZMyW25Fsh0gRIOwaS0C5DwjJA== 
From: "Pilhofer, Frank" <fpilhofe@mc.com> 
To: <issues@omg.org> 
Cc: <deployment-rtf@omg.org> 
X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id j71Hb5hh018303 


This is a new issue for the Deployment RTF.


Section 9.3.5, "SatisfierProperty," defines the concrete
data types that a SatisfierProperty's value can assume,
depending on the SatisfierPropertyKind.


For the "Attribute" kind, it allows the value to be of a
(user-defined) enumeration type. It then says, "if the value
of the SatisfierProperty is of enumeration type, the value
of the Property is of type string, containing the enumeration
value that must compare equal to the SatisfierProperty value.


This is straightforward enough. E.g., it allows a
DomainAdministrator to enumerate the kinds of processors
in a domain,


  enum Processors { ix86, ppc, sparc };


and then to tag each node with a resource containing a
property of this type, its value specifying the actual
processor type of the node.


It seemed like a good idea. Yet this feature does not buy
much. The DomainAdministrator could just as well use an
attribute of type string to the same effect. The only
advantage is that the enumerated property allows the
DomainAdministrator to constrain the values that a
SatisfierProperty may have. But it's the DomainAdmininstrator
constraining himself, so it's not much of a constraint.


However, this feature does add a dependency on DynamicAny
for both the TargetManager and the Planner, which do not
know about any user-defined enumeration types. All the other
SatisfierPropertyKind options use basic IDL data types (long,
unsigned long, double or string).


So, because of the added complexity, and the low mileage, I
propose to remove enumerated properties from the spec.


Proposed resolution:


In section 9.3.5, "SatisfierProperty," change the fourth
and fifth bullet from:


    For the Attribute kind, the value of the SatisfierProperty
    is of type long, double, string, or an enumeration type.
    In the case of long, double or string, the value of the
    Property must be of the same type. If the value of the
    SatisfierProperty is of enumeration type, the value of
    the Property is of type string, containing the enumeration
    value that must compare equal to the SatisfierProperty
    value.


    For the Selection kind, the value of the SatisfierProperty
    is a sequence of type long, double, string, or an
    enumeration type. The same rules as for the Attribute kind
    apply.


To:


    For the Attribute kind, the value of the SatisfierProperty
    is of type long, double or string. The value of the
    Property must be of the same type and compare equal to
    the SatisfierProperty value.


    For the Selection kind, the value of the SatisfierProperty
    is a sequence of type long, double or string. The same
    rules as for the Attribute kind apply.