Issue 2465: Is the multiplicity of Model::Tag::values correct? (mof-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: A Tag has an attribute called "values" with type "any" and multiplicity of [0..*] / ordered == false / unique == false. On thinking about this (while specifying some Tags for the IDL mapping), I"ve concluded that the multiplicity is probably wrong. It would be better if it was either [1..1] or [0..*] / ordered == true / unique == false. Resolution: see below Revised Text: Resolution: Change multiplicity of the 'values' Attribute of Model::Tag to: lower == 0 / upper == UNBOUNDED / ordered == true / unique == false This will consequently change the IDL for the operations corresponding to the attribute. (See below) Revised Text: This change needs to be made in a number of places. -------------------------------------------------------------------------------- In section 3.4.23, change the multiplicity specification for 'values' from "zero or more; not ordered; not unique" to "zero or more; ordered; not unique" In the following IDL, change all 3 occurences of "AnyBag" to "AnyList". Add the following operations: After the "add_values" operation, add: void add_values_before(in any new_element, in any before_element) raises (Reflective::NotFound, Reflective::MofError); void add_values_at(in any new_element, in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); After the "modify_values" operation, add: void modify_values_at(in any new_element, in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); After the "remove_values" operation, add: void remove_values_at(in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); --------------------------------------------------------------------------------- Make the same IDL changes as above to the collected IDL in Appendix B1, and also change typedef sequence < any > AnyBag; to typedef sequence < any > AnyList; --------------------------------------------------------------------------------- Change the MODL for Model in Appendix C as follows: Search for "class Tag : ModelElement" and change attribute bag [0..*] of any values; to attribute list [0..*] of any values; --------------------------------------------------------------------------------- Change the XMI for Model in Appendix A as follows: Search for the string "Contents of Class: Tag", then change <Model.Attribute> <Model.ModelElement.name>values</Model.ModelElement.name> <Model.ModelElement.annotation></Model.ModelElement.annotation> <Model.Feature.visibility xmi.value='public_vis'/> <Model.Feature.scope xmi.value='instance_level'/> <Model.StructuralFeature.multiplicity> <XMI.field>0</XMI.field> <XMI.field>-1</XMI.field> <XMI.field>false</XMI.field> <XMI.field>false</XMI.field> </Model.StructuralFeature.multiplicity> <Model.StructuralFeature.isChangeable xmi.value='true'/> <Model.Attribute.isDerived xmi.value='false'/> <Model.TypedElement.type> <Model.DataType xmi.idref='a101'/> <!-- Model.any --> </Model.TypedElement.type> </Model.Attribute> to read: <Model.Attribute> <Model.ModelElement.name>values</Model.ModelElement.name> <Model.ModelElement.annotation></Model.ModelElement.annotation> <Model.Feature.visibility xmi.value='public_vis'/> <Model.Feature.scope xmi.value='instance_level'/> <Model.StructuralFeature.multiplicity> <XMI.field>0</XMI.field> <XMI.field>-1</XMI.field> <XMI.field>true</XMI.field> <XMI.field>false</XMI.field> </Model.StructuralFeature.multiplicity> <Model.StructuralFeature.isChangeable xmi.value='true'/> <Model.Attribute.isDerived xmi.value='false'/> <Model.TypedElement.type> <Model.DataType xmi.idref='a101'/> <!-- Model.any --> </Model.TypedElement.type> </Model.Attribute> In other word the third "XMI.field" changes from "false" to "true". Actions taken: February 22, 1999: received issue December 3, 2001: closed issue Discussion: We've already decided that the MOF 1.4 IDL will not be upwards compatible with the MOF 1.3 IDL. So adding new operations and (slightly) changing the signatures of existing ones should not be an obstacle. End of Annotations:===== To: mof-rtf@omg.org cc: issues@omg.org Subject: Is the multiplicity of Model::Tag::values correct? Date: Mon, 22 Feb 1999 11:46:06 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Minor Summary: A Tag has an attribute called "values" with type "any" and multiplicity of [0..*] / ordered == false / unique == false. On thinking about this (while specifying some Tags for the IDL mapping), I've concluded that the multiplicity is probably wrong. It would be better if it was either [1..1] or [0..*] / ordered == true / unique == false. Additional text: If a Tag takes more than one value as a "parameter", the order of the parameter values may be significant. Assuming so, this could be expressed as a single "any" containing a CORBA array, sequence or struct, depending on the context. However, it cannot be expressed as a multi-valued any collection, since the multiplicity specification implies that the MOF may not preserve the parameter order. My preference would be to change the multiplicity to [1..1], since that gives a simpler / smaller interface, and since multi-valued Tags are likely to be unusual in practice (IMO). X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 2465: Is the multiplicity of Model::Tag::values correct? Mime-Version: 1.0 Date: Tue, 12 Jun 2001 17:37:37 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: -[%!!+[H!!STEe9(~k!! > Nature: Revision > Severity: Minor > Summary: A Tag has an attribute called "values" with type "any" and > multiplicity of [0..*] / ordered == false / unique == false. On > thinking about this (while specifying some Tags for the IDL > mapping), > I've concluded that the multiplicity is probably wrong. It > would be better if it was either [1..1] or [0..*] / ordered == true > / > unique == false. Proposed resolution: Change multiplicity of the 'values' Attribute of Model::Tag to: lower == 0 / upper == UNBOUNDED / ordered == true / unique == false This will consequently change the IDL for the operations corresponding to the attribute. See below. However, I think we've already decided that the MOF 1.4 IDL will not be upwards compatible with the MOF 1.3 IDL. Revised text: This change needs to be made in a number of places. -------------------------------------------------------------------------------- In section 3.4.23, change the multiplicity specification for 'values' from "zero or more; not ordered; not unique" to "zero or more; ordered; not unique" In the following IDL, change all 3 occurences of "AnyBag" to "AnyList". Add the following operations: After the "add_values" operation, add: void add_values_before(in any new_element, in any before_element) raises (Reflective::NotFound, Reflective::MofError); void add_values_at(in any new_element, in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); After the "modify_values" operation, add: void modify_values_at(in any new_element, in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); After the "remove_values" operation, add: void remove_values_at(in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); --------------------------------------------------------------------------------- Make the same IDL changes as above to the collected IDL in Appendix B1, and also change typedef sequence < any > AnyBag; to typedef sequence < any > AnyList; --------------------------------------------------------------------------------- Change the MODL for Model in Appendix C: Search for "class Tag : ModelElement" and change attribute bag [0..*] of any values; to attribute list [0..*] of any values; --------------------------------------------------------------------------------- Change the XMI for Model in Appendix A: Search for the string "Contents of Class: Tag", then change values 0 -1 false false to read: values 0 -1 true false In other word the third "XMI.field" changes from "false" to "true".