Issue 4482: Optimize Instance data values (cwm-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com) Nature: Enhancement Severity: Significant Summary: The Instances (hence MultiDimensional) metamodel is very wasteful in requiring a separate DataValue object for each simple string slot value: this in effect doubles the number of objects for value-oriented schemas such as Dimension definitions (in MultiDimensional where DataValue is inherited into MemberValue). This is a problem for XMI files and their processing, but even more so for repository implementations which tend to have management overheads associated with each object. Moreover these DataValue objects end up being directly contained in the MemberSet for the Dimension, which surely was not the intention. This means that when navigating from the Dimension to process its Members one also has to filter out a large number of these unwanted Data/MemberValue objects. Resolution: see below Revised Text: In the CWM specification (document formal/2001-10-01), insert the following paragraph as the last paragraph page 4-57 and immediately before Figure 4-7 which appears on page 4-58: Data values may be stored in one of two alternative ways. The Slot class is a generic container that can hold either DataValue or Object instances. One way of storing a data value is to create a Slot instance and place a DataValue instance "in" the Slot via the SlotValue assocation. The alternate way is to create an instance of DataSlot, storing the value into its dataValue attribute. The former method is more general while the latter creates fewer total objects. Both techniques are illustrated in the example in Figure 4-9. Update 4-7 to show added class DataSlot and the association DataSlotType between it and DataType as well as the altered multiplicity for Slot.value, from to Change the last three paragraphs on page 4-59 from George is represented by Object A, and Martha, by Object B. These person objects own Slots C and D, respectively. Slot C holds DataValue E whose value attribute records George’s name. Similarly, Slot D holds Martha’s name in DataValue F. The valid values of the MaritalStatus attribute are recorded by DataValue instances K, L, and M. The marital relationship between George and Martha is represented, from George’s perspective, by Object H which is an instance of the Marriage association. Object H owns Slots G, J, and I. Slot G holds the person association end and references Object A (George), whereas Slot I holds the spouse association end, referencing Object B (Martha). Slot J holds a DataValue instance describing the current value ("Married") of the MaritalStatus attribute for Object H. to George is represented by Object A, and Martha, by Object B. These person objects own DataSlots C and D, respectively, that contain the names of the individuals. The valid values of the MaritalStatus attribute are recorded by DataValue instances I, J, and K. The marital relationship between George and Martha is represented, from George’s perspective, by Object F which is an instance of the Marriage association. Object F owns Slots E, F, and G. Slot E holds the person association end and references Object A (George), whereas Slot G holds the spouse association end, referencing Object B (Martha). Slot H holds a DataValue instance describing the current value ("Married") of the MaritalStatus attribute for Object F. Change Figure 4-9 from to Renumber sections 4.6.1.1 through 4.6.1.5, inclusive, to 4.6.1.2 through 4.6.1.6, respectively. Insert new section 4.6.1.1 before newly renumbered 4.6.1.2 on page 4-61: 4.6.1.1 DataSlot A Slot which is used to hold a data value where there is no need to manage the value as an element in its own right (in which case a DataValue would be used) - for example it is a one-off string value or a number. The dataValue (and dataType where set) must be consistent with the type of the DataSlot's feature (Attribute) and must obey any constraints on the full descriptor of the Attribute's DataType (including both explicit constraints and built-in constraints such as multiplicity). Superclasses Slot Attributes dataValue The value for the slot expressed as a string. type: String multiplicity: exactly one References dataType The type of the dataValue. If not set the type is taken as the type of the Attribute (StructuralFeature) which is the feature for the DataSlot. class: DataType defined-by: DataSlotType::dataType multiplicity: zero or one Constraints A DataType instance associated with a DataSlot instance must be compatible with the type of the DataSlot indicated by the feature::type inherited from Slot. [C-6-6] The StructuralFeature instance obtained via the feature reference inherited from Slot must be an Attribute. [C-6-7] The value reference inherited from Slot must be empty. [C-6-8] In the CWM Rose model (document ad/01-02-07), define the Instances::DataSlot class consistent with its immediately preceding definition in the specification. In the CWM XML file (document ad/01-02-03), add the following definition for the DataSlot class immediately following the definition of Instances::Slot that ends on line 1264 and immediately preceding the definition of Instances::DataValue that begins on line 1265 (note that XML attributes whose values are represented as '<<id>>' will be replaced by appropriate values when the XML file is created by the generation software): <Model:Class xmi.id='<<id>>' name='DataSlot' annotation='A Slot which is used to hold a data value where there is no need to manage the value as an element in its own right (in which case a DataValue would be used) - for example it is a one-off string value or a number. The dataValue (and dataType where set) must be consistent with the type of the DataSlot's feature (Attribute) and must obey any constraints on the full descriptor of the Attribute's DataType (including both explicit constraints and built-in constraints such as multiplicity).' isRoot='false' isLeaf='false' isAbstract='false' visibility='public_vis' isSingleton='false' supertypes='<<id>>'> <Model:Namespace.contents> <Model:Attribute xmi.id='<<id>>' name='dataValue' annotation='The value for the slot expressed as a string.' scope='instance_level' visibility='public_vis' isChangeable='true' isDerived='false' type='<<id>>'> <Model:StructuralFeature.multiplicity> <XMI.field>1</XMI.field> <!-- lower --> <XMI.field>1</XMI.field> <!-- upper --> <XMI.field>false</XMI.field> <!-- is_ordered --> <XMI.field>false</XMI.field> <!-- is_unique --> </Model:StructuralFeature.multiplicity> </Model:Attribute> <Model:Reference xmi.id='<<id>>' name='dataType' annotation='The type of the dataValue. If not set the type is taken as the type of the Attribute (StructuralFeature) which is the feature for the DataSlot.' scope='instance_level' visibility='public_vis' isChangeable='true' type='<<id>>' referencedEnd='<<id>>'> <Model:StructuralFeature.multiplicity> <XMI.field>0</XMI.field> <!-- lower --> <XMI.field>1</XMI.field> <!-- upper --> <XMI.field>false</XMI.field> <!-- is_ordered --> <XMI.field>false</XMI.field> <!-- is_unique --> </Model:StructuralFeature.multiplicity> </Model:Reference> </Model:Namespace.contents> </Model:Class> In the CWM IDL zip file (document ad/01-02-06), add the following interface definitions for the DataSlot class in the Instances.idl file: Between lines 14 and 15, insert: interface DataSlotClass; interface DataSlot; typedef sequence<DataSlot> DataSlotSet; Between lines 66 and 67, insert: interface DataSlotClass : InstanceClass { readonly attribute DataSlotSet all_of_type_slot; readonly attribute DataSlotSet all_of_class_slot; DataSlot create_data_slot ( in Core::Name name, in Core::VisibilityKind visibility in string data_value) raises (Reflective::MofError); }; interface DataSlot : DataSlotClass, Instance { string data_value () raises (Reflective::MofError); void set_data_value (in string new_value) raises (Reflective::MofError); Core::DataType data_type () raises (Reflective::NotSet, Reflective::MofError); void set_data_type (in Core::DataType new_value) raises (Reflective::MofError); void unset_data_type () raises (Reflective::MofError); }; // end of interface DataSlot In the CWM specification (formal/2001-10-01), change the multiplicity of the Slot::value reference in newly numbered section 4.6.1.6 on page 4-64 from "exactly one" to "zero or more". In the CWM XML file (ad/01-02-03), change the multiplicity lower bound of the Slot::value reference at line 1249 from <XMI.field>1</XMI.field> <!-- lower --> to <XMI.field>0</XMI.field> <!-- lower --> In the CWM IDL file (ad/01-02-06), insert the following lines between lines 60 and 61: void unset_value () raises (Reflective::MofError); In newly numbered section 4.6.1.6 of the CWM specification (formal/2001-10-01), add a new constraint at the end of the list of Constraints on page 4-64: If the Slot instance is not also a DataSlot, the value reference must be present. [C-6-9] In the CWM specification (formal/2001-10-01), renumber sections 4.6.2.1 through 4.6.2.4, inclusive, to 4.6.2.2 through 4.6.2.5, respectively. In the CWM specification (formal/2001-10-01), insert new section 4.6.2.1 before newly numbered 4.6.2.2 (formal/2001-10-01, page 4-65), with the text: 4.6.2.1 DataSlotType The DataSlotType association connects DataSlot instances with the DataType instance that identifies the type of information stored in the DataSlot::dataValue attribute. Ends dataSlot Identifies the DataSlot instances for which the DataType instance is the type of information stored in the DataSlot::dataValue attribute. class: DataSlot multiplicity: zero or more dataType Identifies the DataType instance representing the type of the information stored in the dataValue attribute. class: DataType multiplicity: zero or more In the CWM XML file (document ad/01-02-03), add the following definition for the DataSlotType association immediately following the definition of Instances::FeatureSlot that ends on line 1378 and immediately preceding the Model.Namespace.contents end tag on line 1379 (note that XML attributes whose values are represented as '<<id>>' will be replaced by appropriate values when the XML file is created by the generation software): <Model:Association xmi.id='<<id>>' name='DataSlotType' annotation='The DataSlotType association connects DataSlot instances with the DataType instance that identifies the type of information stored in the DataSlot::dataValueattribute.' isRoot='true' isLeaf='true' isAbstract='false' visibility='public_vis' isDerived='false'> <Model:Namespace.contents> <Model:AssociationEnd xmi.id='<<id>>' name='dataSlot' annotation='Identifies the DataSlot instances for which the DataType instance is the type of information stored in the DataSlot::dataValue attribute.' isNavigable='true' aggregation='none' isChangeable='true' type='<<id>>'> <Model:AssociationEnd.multiplicity> <XMI.field>0</XMI.field> <!-- lower --> <XMI.field>-1</XMI.field> <!-- upper --> <XMI.field>false</XMI.field> <!-- is_ordered --> <XMI.field>true</XMI.field> <!-- is_unique --> </Model:AssociationEnd.multiplicity> </Model:AssociationEnd> <Model:AssociationEnd xmi.id='<<id>>' name='dataType' annotation='Identifies the DataType instance representing the type of the information stored in the dataValue attribute.' isNavigable='true' aggregation='none' isChangeable='true' type='<<id>>'> <Model:AssociationEnd.multiplicity> <XMI.field>0</XMI.field> <!-- lower --> <XMI.field>-1</XMI.field> <!-- upper --> <XMI.field>false</XMI.field> <!-- is_ordered --> <XMI.field>false</XMI.field> <!-- is_unique --> </Model:AssociationEnd.multiplicity> </Model:AssociationEnd> </Model:Namespace.contents> </Model:Association> In the CWM IDL zip file (document ad/01-02-06), add the following interface definitions for the DataSlotType association in the Instances.idl file: struct DataSlotTypeLink { DataSlot data_slot; Core::DataType data_type; }; typedef sequence<DataSlotTypeLink> DataSlotTypeLinkSet; interface DataSlotType : Reflective::RefAssociation { DataSlotTypeLinkSet all_data_slot_type_links() raises (Reflective::MofError); boolean exists ( in DataSlot data_slot, in Core::DataType data_type) raises (Reflective::MofError); DataSlotSet data_slot (in Core::DataType data_type) raises (Reflective::MofError); Core::DataType data_type (in DataSlot data_slot) raises (Reflective::MofError); void add ( in DataSlot data_slot, in Core::DataType data_type) raises (Reflective::MofError); void modify_data_slot ( in DataSlot data_slot, in Core::DataType data_type, in DataSlot new_data_slot) raises (Reflective::NotFound, Reflective::MofError); void modify_data_type ( in DataSlot data_slot, in Core::DataType data_type, in Core::DataType new_data_type) raises (Reflective::NotFound, Reflective::MofError); void remove ( in DataSlot data_slot, in Core::DataType data_type) raises (Reflective::NotFound, Reflective::MofError); }; // end of interface DataSlotType In the CWM specification (formal/2001-10-01), add the following constraints to the end of the list of Constraints on page 4-67: [C-6-6] A DataType instance associated with a DataSlot instance must be compatible with the type of the DataSlot indicated by the feature::type inherited from Slot. context DataSlot inv: self.dataType->notEmpty implies self.dataType.oclIsKindOf(self.feature.type) [C-6-7] The StructuralFeature instance obtained via the feature reference inherited from Slot must be an Attribute. context DataSlot inv: self.feature.oclIsTypeOf(Attribute) [C-6-8] The value reference inherited from Slot must be empty. context DataSlot inv: self.value->isEmpty() [C-6-9] If the Slot instance is not also a DataSlot, the value reference must be present. context Slot inv: self.oclIsTypeOf(Slot) implies self.value->notEmpty() Actions taken: August 10, 2001: received issue May 13, 2002: closed issue Discussion: Proposed resolution ------------------- a) Add new subclass of Slot called 'DataSlot' with description: "A Slot which is used to hold a data value where there is no need to manage the value as an element in its own right (in which case a DataValue would be used) - for example it is a one-off string value or a number." b) Add String attribute 'dataValue', description: "The value for the slot expressed as a string." c) Add reference 'dataType'[0..1] to DataType, description: "The type of the dataValue. If not set the type is taken as the type of the StructuralFeature associated with the DataSlot." d) Add constraint that DataSlot.value (reference inherited from Slot) must be empty. e) Update Figure 7-6-3 to change the 2 instances of Slot associated with the 'name' Attribute to be instances of DataSlot, delete the attached instances of DataValue, and attach the 'value=' strings directly to the DataSlots making them 'dataValue='. Rationale --------- This is intended to be a minimal-impact proposal that is incremental and does not impact existing implementations. It does not replace the existing DataValue class where there is the real need to have stand-alone managed data values (the equivalent of Constant in MOF and EnumerationLiteral in UML), but is for use where the values are pure one-off values for which the overhead of a separate ModelElement is not justified: for example most numeric and string values. The George and Martha example in Figure 7-6-3 illustrates the distinction: for the one-off names "George Washington" and "Martha Custis Washington" then the new DataSlot is used, but for the pseudo-enumeration values associated with the MaritalStatus attribute ("Married", "Widowed", "Divorced") then DataValue is still used: in particular because some of the values (e.g. "Divorced") are not yet associated with any actual Slot. a) Add new subclass of Slot called 'DataSlot' with description: "A Slot which is used to hold a data value where there is no need to manage the value as an element in its own right (in which case a DataValue would be used) - for example it is a one-off string value or a number. The dataValue (and dataType where set) must be consistent with the type of the DataSlot's feature (Attribute) and must obey any constraints on the full descriptor of the Attribute's DataType (including both explicit constraints and built-in constraints such as multiplicity)." b) Add String attribute 'dataValue', description: "The value for the slot expressed as a string." c) Add reference 'dataType'[0..1] to DataType, description: "The type of the dataValue. If not set the type is taken as the type of the Attribute (StructuralFeature) which is the feature for the DataSlot. " d) Add constraint that the feature of a DataSlot must be an Attribute. In OCL: self.feature.oclIsTypeOf(Attribute). e) Add constraint that a DataType associated with a DataSlot must be type compatible with that associated with the Attribute which is its feature. In OCL: self.dataType.oclIsKindOf(self.feature.type). f) Change multiplicity of reference Slot.value from 1 to 0..1 and add constraints that it must not be empty for direct instances of Slot and must be empty for instances of DataSlot. In OCL: [on Slot] self.oclIsTypeOf(Slot)implies self.value->notEmpty() and [on DataSlot] self.value->isEmpty(). g) Update Figure 7-6-3 to change the 2 instances of Slot associated with the'name' Attribute to be instances of DataSlot, delete the attached instances of DataValue, and attach the 'value=' strings directly to the DataSlots making them 'dataValue='. End of Annotations:===== From: webmaster@omg.org Message-Id: <200108101419.f7AEJLt19360@emerald.omg.org> Date: 10 Aug 2001 10:22:30 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: ;I~e9Vf:!!OZN!!=e)e9 Name: Pete Rivett Company: Adptive mailFrom: pete.rivett@adaptive.com Notification: Yes Specification: CWM Section: 7.6 or 11 FormalNumber: ad/01-02-01 Version: 1.0 RevisionDate: 2/2/2001 Page: 7-126 to 7-129 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Description Optimize Instance data values ----------------------------- The Instances (hence MultiDimensional) metamodel is very wasteful in requiring a separate DataValue object for each simple string slot value: this in effect doubles the number of objects for value-oriented schemas such as Dimension definitions (in MultiDimensional where DataValue is inherited into MemberValue). This is a probem for XMI files and their processing, but even more so for repository implementations which tend to have management overheads associated with each object. Moreover these DataValue objects end up being directly contained in the MemberSet for the Dimension, which surely was not the intention. This means that when navigating from the Dimension to process its Members one also has to filter out a large number of these unwanted Data/MemberValue objects. To me it would seem preferable to add an attribute "dataValue: String" directly on the Slot class. There is no practical benefit in having the link from dataValue to Classifier (DataType), since this is already linked from the Attribute defining the Slot (and the ability for a data value to be of a subtype seems too obscure in comparison to the cost). Proposed resolution - I present 2 alternatives, one in the Instance metamodel and one in MultiDimensional. In my view it is preferable to fix Instance (since then it helps Relational and other resource models which may need a large number of values). However fixing Instance raises the issue of synchronization with UML from which it is borrowed: I guess we could make the fix in CWM and raise an issue on UML 1.5 suggesting they do the same. In both cases I have maximized forward compatibility by retaining the DataValue class, though strictly speaking it is redundant/obsolescent and should be deprecated. Alternative A) - fix Instances metamodel Introduce new class DataSlot which is subclass of Slot. It has a single String attribute 'dataValue' (1..1). The following constraint is associated: DataSlot.value = empty Alternative B) - fix Multidimensional metamodel. Introduce new class MemberDataSlot which is subclass of Instance.Slot. It has a single String attribute 'dataValue' (1..1). The following constraint is associated: MemberDataSlot.value = empty From: "Pete Rivett" To: Subject: FYI new issue re Data Values Date: Fri, 10 Aug 2001 15:27:13 +0100 Message-ID: <001a01c121a8$8d935570$114c04c8@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >I=e9/BA!!2S1!!@3dd9 I've just raised this on the OMG web site. The current spec causes real implementation problems in this area for no benefit. Optimize Instance data values ----------------------------- The Instances (hence MultiDimensional) metamodel is very wasteful in requiring a separate DataValue object for each simple string slot value: this in effect doubles the number of objects for value-oriented schemas such as Dimension definitions (in MultiDimensional where DataValue is inherited into MemberValue). This is a probem for XMI files and their processing, but even more so for repository implementations which tend to have management overheads associated with each object. Moreover these DataValue objects end up being directly contained in the MemberSet for the Dimension, which surely was not the intention. This means that when navigating from the Dimension to process its Members one also has to filter out a large number of these unwanted Data/MemberValue objects. To me it would seem preferable to add an attribute "dataValue: String" directly on the Slot class. There is no practical benefit in having the link from dataValue to Classifier (DataType), since this is already linked from the Attribute defining the Slot (and the ability for a data value to be of a subtype seems too obscure in comparison to the cost). Proposed resolution - I present 2 alternatives, one in the Instance metamodel and one in MultiDimensional. In my view it is preferable to fix Instance (since then it helps Relational and other resource models which may need a large number of values). However fixing Instance raises the issue of synchronization with UML from which it is borrowed: I guess we could make the fix in CWM and raise an issue on UML 1.5 suggesting they do the same. In both cases I have maximized forward compatibility by retaining the DataValue class, though strictly speaking it is redundant/obsolescent and should be deprecated. Alternative A) - fix Instances metamodel Introduce new class DataSlot which is subclass of Slot. It has a single String attribute 'dataValue' (1..1). The following constraint is associated: DataSlot.value = empty Alternative B) - fix Multidimensional metamodel. Introduce new class MemberDataSlot which is subclass of Instance.Slot. It has a single String attribute 'dataValue' (1..1). The following constraint is associated: MemberDataSlot.value = empty Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: Re: FYI new issue re Data Values To: "Pete Rivett" Cc: From: John_Poole@hyperion.com Date: Fri, 10 Aug 2001 11:07:49 -0400 Message-ID: X-MIMETrack: Serialize by Router on Stmfd-Gateway1/na/Hyperion(Release 5.0.5 |September 22, 2000) at 08/10/2001 11:07:57 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: on 08/10/2001 10:27:13 AM To: cc: Subject: FYI new issue re Data Values I've just raised this on the OMG web site. The current spec causes real implementation problems in this area for no benefit. Optimize Instance data values ----------------------------- The Instances (hence MultiDimensional) metamodel is very wasteful in requiring a separate DataValue object for each simple string slot value: this in effect doubles the number of objects for value-oriented schemas such as Dimension definitions (in MultiDimensional where DataValue is inherited into MemberValue). This is a probem for XMI files and their processing, but even more so for repository implementations which tend to have management overheads associated with each object. Moreover these DataValue objects end up being directly contained in the MemberSet for the Dimension, which surely was not the intention. This means that when navigating from the Dimension to process its Members one also has to filter out a large number of these unwanted Data/MemberValue objects. To me it would seem preferable to add an attribute "dataValue: String" directly on the Slot class. There is no practical benefit in having the link from dataValue to Classifier (DataType), since this is already linked from the Attribute defining the Slot (and the ability for a data value to be of a subtype seems too obscure in comparison to the cost). Proposed resolution - I present 2 alternatives, one in the Instance metamodel and one in MultiDimensional. In my view it is preferable to fix Instance (since then it helps Relational and other resource models which may need a large number of values). However fixing Instance raises the issue of synchronization with UML from which it is borrowed: I guess we could make the fix in CWM and raise an issue on UML 1.5 suggesting they do the same. In both cases I have maximized forward compatibility by retaining the DataValue class, though strictly speaking it is redundant/obsolescent and should be deprecated. Alternative A) - fix Instances metamodel Introduce new class DataSlot which is subclass of Slot. It has a single String attribute 'dataValue' (1..1). The following constraint is associated: DataSlot.value = empty Alternative B) - fix Multidimensional metamodel. Introduce new class MemberDataSlot which is subclass of Instance.Slot. It has a single String attribute 'dataValue' (1..1). The following constraint is associated: MemberDataSlot.value = empty Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. From: "Pete Rivett" To: Cc: Subject: CWM Issue 4482: Optimize Instance data values Date: Mon, 24 Sep 2001 01:35:35 +0100 Message-ID: <002801c14490$d449a4a0$1ea423d9@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: +CTd9og^!!;`/!!#R9!! Status: RO >From the Toronto meeting I took an action to make a new proposed resolution with examples. Here it is in textual form. I have submitted a revised instance.cat (and a HTML-published version of the same) in the following file [may take a little while to get posted] http://cgi.omg.org/pub/cwm_rtf/InstancesIssue4482.zip. [Juergen please update the issues database with the following] The text for the Issue should now read: Summary: The Instances (hence MultiDimensional) metamodel is very wasteful in requiring a separate DataValue object for each simple string slot value: this in effect doubles the number of objects for value-oriented schemas such as Dimension definitions (in MultiDimensional where DataValue is inherited into MemberValue). This is a problem for XMI files and their processing, but even more so for repository implementations which tend to have management overheads associated with each object. Moreover these DataValue objects end up being directly contained in the MemberSet for the Dimension, which surely was not the intention. This means that when navigating from the Dimension to process its Members one also has to filter out a large number of these unwanted Data/MemberValue objects. Proposed resolution ------------------- a) Add new subclass of Slot called 'DataSlot' with description: "A Slot which is used to hold a data value where there is no need to manage the value as an element in its own right (in which case a DataValue would be used) - for example it is a one-off string value or a number." b) Add String attribute 'dataValue', description: "The value for the slot expressed as a string." c) Add reference 'dataType'[0..1] to DataType, description: "The type of the dataValue. If not set the type is taken as the type of the StructuralFeature associated with the DataSlot." d) Add constraint that DataSlot.value (reference inherited from Slot) must be empty. e) Update Figure 7-6-3 to change the 2 instances of Slot associated with the 'name' Attribute to be instances of DataSlot, delete the attached instances of DataValue, and attach the 'value=' strings directly to the DataSlots making them 'dataValue='. Rationale --------- This is intended to be a minimal-impact proposal that is incremental and does not impact existing implementations. It does not replace the existing DataValue class where there is the real need to have stand-alone managed data values (the equivalent of Constant in MOF and EnumerationLiteral in UML), but is for use where the values are pure one-off values for which the overhead of a separate ModelElement is not justified: for example most numeric and string values. The George and Martha example in Figure 7-6-3 illustrates the distinction: for the one-off names "George Washington" and "Martha Custis Washington" then the new DataSlot is used, but for the pseudo-enumeration values associated with the MaritalStatus attribute ("Married", "Widowed", "Divorced") then DataValue is still used: in particular because some of the values (e.g. "Divorced") are not yet associated with any actual Slot. The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. Subject: Issue 4482 To: "Pete Rivett" Cc: cwm-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Tue, 25 Sep 2001 15:54:10 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/25/2001 04:54:12 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: VQ(!!;7^!!9dU!!>J2e9 Pete, I suggest that c) be revised as follows: c) Add reference 'dataType' [1] to DataType, description": "The type of the dataValue." Rationale: 1) Consistent with DataValue/Instance having a reference 'classifier' [1] to Classifier. 2) Avoid misinterpretation (if dataType is left out by error). 3) Avoid processing (to find dataType through StructuredFeature through type). Regards, Dan Metadata Management Technology and Standard IBM DBTI for e-Business Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 Subject: Call for Vote on Issue 4482 To: cwm-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Dan Chang" Date: Thu, 27 Sep 2001 14:17:18 -0700 X-MIMETrack: Serialize by Router on D03NM069/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/27/2001 03:17:20 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: IHN!!<$~e9L[8e9#)Ee9 Team, The following is a call for vote on Issue 4482 whose proposed resolution (A or B) was agreed upon by all participants of this morning's telecon. For those of you who are voting members of the CWM RTF, please vote early. Regards, Dan CALL FOR VOTE: --------------------------- This e-mail is a call for vote for Issue 4482. Vote starts on September 28, 2001. Vote ends on October 2, 2001. Please vote YES (A or B), NO or ABSTAIN on accepting the proposed resolution for this issue. Regards, Dan ================ Issue 4482 Optimize Instance data values Summary: The Instances (hence MultiDimensional) metamodel is very wasteful in requiring a separate DataValue object for each simple string slot value: this in effect doubles the number of objects for value-oriented schemas such as Dimension definitions (in MultiDimensional where DataValue is inherited into MemberValue). This is a problem for XMI files and their processing, but even more so for repository implementations which tend to have management overheads associated with each object. Moreover these DataValue objects end up being directly contained in the MemberSet for the Dimension, which surely was not the intention. This means that when navigating from the Dimension to process its Members one also has to filter out a large number of these unwanted Data/MemberValue objects. Proposed resolution A --------------------- (see also http://cgi.omg.org/pub/cwm_rtf/InstancesIssue4482.zip (which contains both the Rose Instance.cat file and the Rose web published form but does not reflect item f) below: the value reference is still shown as multiplicity 1 but should be 0..1). ------------------- a) Add new subclass of Slot called 'DataSlot' with description: "A Slot which is used to hold a data value where there is no need to manage the value as an element in its own right (in which case a DataValue would be used) - for example it is a one-off string value or a number. The dataValue (and dataType where set) must be consistent with the type of the DataSlot's feature (Attribute) and must obey any constraints on the full descriptor of the Attribute's DataType (including both explicit constraints and built-in constraints such as multiplicity)." b) Add String attribute 'dataValue', description: "The value for the slot expressed as a string." c) Add reference 'dataType'[0..1] to DataType, description: "The type of the dataValue. If not set the type is taken as the type of the Attribute (StructuralFeature) which is the feature for the DataSlot. " d) Add constraint that the feature of a DataSlot must be an Attribute. In OCL: self.feature.oclIsTypeOf(Attribute). e) Add constraint that a DataType associated with a DataSlot must be type compatible with that associated with the Attribute which is its feature. In OCL: self.dataType.oclIsKindOf(self.feature.type). f) Change multiplicity of reference Slot.value from 1 to 0..1 and add constraints that it must not be empty for direct instances of Slot and must be empty for instances of DataSlot. In OCL: [on Slot] self.oclIsTypeOf(Slot) implies self.value->notEmpty() and [on DataSlot] self.value->isEmpty(). g) Update Figure 7-6-3 to change the 2 instances of Slot associated with the 'name' Attribute to be instances of DataSlot, delete the attached instances of DataValue, and attach the 'value=' strings directly to the DataSlots making them 'dataValue='. Rationale --------- This is intended to be a minimal-impact proposal that is incremental and does not impact existing implementations. It does not replace the existing DataValue class where there is the real need to have stand-alone managed data values (the equivalent of Constant in MOF and EnumerationLiteral in UML), but is for use where the values are pure one-off values for which the overhead of a separate ModelElement is not justified: for example most numeric and string values. The George and Martha example in Figure 7-6-3 illustrates the distinction: for the one-off names "George Washington" and "Martha Custis Washington" then the new DataSlot is used, but for the pseudo-enumeration values associated with the MaritalStatus attribute ("Married", "Widowed", "Divorced") then DataValue is still used: in particular because some of the values (e.g. "Divorced") are not yet associated with any actual Slot. The reference from DataSlot to DataType is optional in order to support minimal datavalue representations and those that do not put an onus on receiving applications to check the DataSlot DataType against that associated with the Attribute. Proposed resolution B --------------------- This is identical to the proposed resolution A except for item c) which is revised as follows: c) Add reference 'dataType'[1] to DataType, description: "The type of the dataValue." Rationale --------- The reference from DataSlot to DataType is mandatory in order to: 1)maintain consistency with DataValue, which has a mandatory reference 'classifier' to DataType, 2)maintain uniformity in XMI files (All DataSlot elements have a dataType attribute. With the proposed resolution A, some DataSlot elements must have a dataType attribute, while others may or may not have a dataType attribute.) 3)avoid conditional and additional processing (All DataSlots have a dataType reference pointing to the data type. With the proposed resolution A, some DataSlots must have a dataType reference pointing to the data type, while other DataSlots may or may not have a dataType reference, in the later case the data type must be indirectly derived through the associated Attribute/ StructuredFeature and its type reference.) From: "Tolbert, Doug M" To: cwm-rtf@omg.org Subject: RE: Call for Vote on Issue 4482 Date: Mon, 15 Oct 2001 13:17:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: E&~!!'$jd9be]!!boYd9 Folks, While attempting to add Issue 4482-A (below) to the model .mdl file, I ran across the following anomaly. This note describes the problem and a resolution. Problem: Item (c) adds a reference called "dataType" to DataSlot. Having such a reference implies the existence of an association between DataSlot and Core::DataType that can be used to implement the reference. Unfortunately, no such association exists in CWM 1.0 and Issue 4482-A does not ask that one be added. Item (e) and the last paragraph of the Rationale section clearly imply that the association implementing the dataType reference is not the same as the inherited "type" association between Core::StructuralFeature and Core::Classifier that can be reached via the "feature" reference of Slot. Also, the OCL stated in Item (e) does not allow the dataType reference to be optional. The fix is: Add a new association called DataSlotType, with ends dataSlot [*] and dataType [0..1], between DataSlot and Core::DataType. Note that because the new association crosses package boundries, it will not be marked "Protected" in the specification. Relevant descriptions are: DataSlotType = "The DataSlotType association connects DataSlot instances with the Core::DataType instance that identifies the type of information stored in the DataSlot::dataValue attribute.", dataSlot = "Identifies the DataSlot instances for which the DataType instance is the type of information stored in the DataSlot::dataValue attribute.", dataType = "Identifies the DataType instance representing the type of the information stored in the dataValue attribute.". Change the OCLs stated in Item (e) to "self.dataType->isNotEmpty implies self.dataType.oclIsKindOf(self.feature.type)". As it currently stands, Issue 4482-A CANNOT BE IMPLEMENTED without adding this assocation and changing the OCL. Consequently, I will added it to the model and spec updates I'm preparing. If y'all want to do something else, complain loudly and immediately. Doug -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Thursday, September 27, 2001 2:17 PM To: cwm-rtf@omg.org Subject: Call for Vote on Issue 4482 Team, The following is a call for vote on Issue 4482 whose proposed resolution (A or B) was agreed upon by all participants of this morning's telecon. For those of you who are voting members of the CWM RTF, please vote early. Regards, Dan CALL FOR VOTE: --------------------------- This e-mail is a call for vote for Issue 4482. Vote starts on September 28, 2001. Vote ends on October 2, 2001. Please vote YES (A or B), NO or ABSTAIN on accepting the proposed resolution for this issue. Regards, Dan ================ Issue 4482 Optimize Instance data values Summary: The Instances (hence MultiDimensional) metamodel is very wasteful in requiring a separate DataValue object for each simple string slot value: this in effect doubles the number of objects for value-oriented schemas such as Dimension definitions (in MultiDimensional where DataValue is inherited into MemberValue). This is a problem for XMI files and their processing, but even more so for repository implementations which tend to have management overheads associated with each object. Moreover these DataValue objects end up being directly contained in the MemberSet for the Dimension, which surely was not the intention. This means that when navigating from the Dimension to process its Members one also has to filter out a large number of these unwanted Data/MemberValue objects. Proposed resolution A --------------------- (see also http://cgi.omg.org/pub/cwm_rtf/InstancesIssue4482.zip (which contains both the Rose Instance.cat file and the Rose web published form but does not reflect item f) below: the value reference is still shown as multiplicity 1 but should be 0..1). ------------------- a) Add new subclass of Slot called 'DataSlot' with description: "A Slot which is used to hold a data value where there is no need to manage the value as an element in its own right (in which case a DataValue would be used) - for example it is a one-off string value or a number. The dataValue (and dataType where set) must be consistent with the type of the DataSlot's feature (Attribute) and must obey any constraints on the full descriptor of the Attribute's DataType (including both explicit constraints and built-in constraints such as multiplicity)." b) Add String attribute 'dataValue', description: "The value for the slot expressed as a string." c) Add reference 'dataType'[0..1] to DataType, description: "The type of the dataValue. If not set the type is taken as the type of the Attribute (StructuralFeature) which is the feature for the DataSlot. " d) Add constraint that the feature of a DataSlot must be an Attribute. In OCL: self.feature.oclIsTypeOf(Attribute). e) Add constraint that a DataType associated with a DataSlot must be type compatible with that associated with the Attribute which is its feature. In OCL: self.dataType.oclIsKindOf(self.feature.type). f) Change multiplicity of reference Slot.value from 1 to 0..1 and add constraints that it must not be empty for direct instances of Slot and must be empty for instances of DataSlot. In OCL: [on Slot] self.oclIsTypeOf(Slot) implies self.value->notEmpty() and [on DataSlot] self.value->isEmpty(). g) Update Figure 7-6-3 to change the 2 instances of Slot associated with the 'name' Attribute to be instances of DataSlot, delete the attached instances of DataValue, and attach the 'value=' strings directly to the DataSlots making them 'dataValue='. Rationale --------- This is intended to be a minimal-impact proposal that is incremental and does not impact existing implementations. It does not replace the existing DataValue class where there is the real need to have stand-alone managed data values (the equivalent of Constant in MOF and EnumerationLiteral in UML), but is for use where the values are pure one-off values for which the overhead of a separate ModelElement is not justified: for example most numeric and string values. The George and Martha example in Figure 7-6-3 illustrates the distinction: for the one-off names "George Washington" and "Martha Custis Washington" then the new DataSlot is used, but for the pseudo-enumeration values associated with the MaritalStatus attribute ("Married", "Widowed", "Divorced") then DataValue is still used: in particular because some of the values (e.g. "Divorced") are not yet associated with any actual Slot. The reference from DataSlot to DataType is optional in order to support minimal datavalue representations and those that do not put an onus on receiving applications to check the DataSlot DataType against that associated with the Attribute. Proposed resolution B --------------------- This is identical to the proposed resolution A except for item c) which is revised as follows: c) Add reference 'dataType'[1] to DataType, description: "The type of the dataValue." Rationale --------- The reference from DataSlot to DataType is mandatory in order to: 1)maintain consistency with DataValue, which has a mandatory reference 'classifier' to DataType, 2)maintain uniformity in XMI files (All DataSlot elements have a dataType attribute. With the proposed resolution A, some DataSlot elements must have a dataType attribute, while others may or may not have a dataType attribute.) 3)avoid conditional and additional processing (All DataSlots have a dataType reference pointing to the data type. With the proposed resolution A, some DataSlots must have a dataType reference pointing to the data type, while other DataSlots may or may not have a dataType reference, in the later case the data type must be indirectly derived through the associated Attribute/ StructuredFeature and its type reference.) From: "Pete Rivett" To: "'Tolbert, Doug M'" , Subject: RE: Call for Vote on Issue 4482 Date: Mon, 15 Oct 2001 20:56:47 +0100 Message-ID: <005801c155b3$8677f540$54a223d9@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <97F39596DEEECF11BC020000C09361E502EE2B36@mv_exchange_2.mv.unisys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 8aWd9~?Rd97p*e9&~Y!! Yes, Doug, the fix you applied was the intention: an oversight on my part to not explicitly back up the new Reference with an Association. Regards, Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Tolbert, Doug M [mailto:Doug.Tolbert@unisys.com] > Sent: 15 October 2001 19:17 > To: cwm-rtf@omg.org > Subject: RE: Call for Vote on Issue 4482 > > > Folks, > > While attempting to add Issue 4482-A (below) to the model > .mdl file, I ran > across the following anomaly. This note describes the problem and a > resolution. > > Problem: Item (c) adds a reference called "dataType" to > DataSlot. Having > such a reference implies the existence of an association > between DataSlot > and Core::DataType that can be used to implement the reference. > Unfortunately, no such association exists in CWM 1.0 and > Issue 4482-A does > not ask that one be added. Item (e) and the last paragraph > of the Rationale > section clearly imply that the association implementing the dataType > reference is not the same as the inherited "type" association between > Core::StructuralFeature and Core::Classifier that can be > reached via the > "feature" reference of Slot. Also, the OCL stated in Item > (e) does not > allow the dataType reference to be optional. > > The fix is: > > Add a new association called DataSlotType, with ends dataSlot [*] and > dataType [0..1], between DataSlot and Core::DataType. Note > that because the > new association crosses package boundries, it will not be > marked "Protected" > in the specification. Relevant descriptions are: DataSlotType = "The > DataSlotType association connects DataSlot instances with the > Core::DataType > instance that identifies the type of information stored in the > DataSlot::dataValue attribute.", dataSlot = "Identifies the DataSlot > instances for which the DataType instance is the type of > information stored > in the DataSlot::dataValue attribute.", dataType = > "Identifies the DataType > instance representing the type of the information stored in > the dataValue > attribute.". Change the OCLs stated in Item (e) to > "self.dataType->isNotEmpty implies > self.dataType.oclIsKindOf(self.feature.type)". > > As it currently stands, Issue 4482-A CANNOT BE IMPLEMENTED > without adding > this assocation and changing the OCL. Consequently, I will > added it to the > model and spec updates I'm preparing. > > If y'all want to do something else, complain loudly and immediately. > > Doug > > > > -----Original Message----- > From: Dan Chang [mailto:dtchang@us.ibm.com] > Sent: Thursday, September 27, 2001 2:17 PM > To: cwm-rtf@omg.org > Subject: Call for Vote on Issue 4482 > > > Team, > > The following is a call for vote on Issue 4482 whose proposed > resolution (A > or B) > was agreed upon by all participants of this morning's > telecon. For those of > you who are voting members of the CWM RTF, please vote early. > > Regards, Dan > > > CALL FOR VOTE: > --------------------------- > > This e-mail is a call for vote for Issue 4482. Vote starts on > September 28, > 2001. Vote ends on October 2, 2001. > > Please vote YES (A or B), NO or ABSTAIN on accepting the proposed > resolution for > this issue. > > > Regards, Dan > > > ================ > Issue 4482 Optimize Instance data values > Summary: The Instances (hence MultiDimensional) metamodel is > very wasteful > in requiring a separate DataValue object for each simple > string slot value: > this in effect doubles the number of objects for > value-oriented schemas > such > as Dimension definitions (in MultiDimensional where DataValue > is inherited > into MemberValue). This is a problem for XMI files and their > processing, > but > even more so for repository implementations which tend to > have management > overheads associated with each object. Moreover these > DataValue objects end > up being directly contained in the MemberSet for the Dimension, which > surely > was not the intention. This means that when navigating from > the Dimension > to > process its Members one also has to filter out a large number of these > unwanted Data/MemberValue objects. > > Proposed resolution A > --------------------- > (see also > http://cgi.omg.org/pub/cwm_rtf/InstancesIssue4482.zip (which > contains both > the Rose Instance.cat file and the Rose web published form > but does not > reflect item f) below: the value reference is still shown as > multiplicity 1 > but should be 0..1). > ------------------- > a) Add new subclass of Slot called 'DataSlot' with > description: "A Slot > which is used to hold a data value where there is no need to > manage the > value as an element in its own right (in which case a > DataValue would be > used) - for example it is a one-off string value or a number. > The dataValue (and dataType where set) must be consistent > with the type of > the DataSlot's feature (Attribute) and must obey any > constraints on the > full > descriptor of the Attribute's DataType (including both > explicit constraints > and built-in constraints such as multiplicity)." > b) Add String attribute 'dataValue', description: "The value > for the slot > expressed as a string." > c) Add reference 'dataType'[0..1] to DataType, description: > "The type of > the > dataValue. If not set the type is taken as the type of the Attribute > (StructuralFeature) which is the feature for the DataSlot. " > d) Add constraint that the feature of a DataSlot must be an > Attribute. In > OCL: self.feature.oclIsTypeOf(Attribute). > e) Add constraint that a DataType associated with a DataSlot > must be type > compatible with that associated with the Attribute which is > its feature. In > OCL: self.dataType.oclIsKindOf(self.feature.type). > f) Change multiplicity of reference Slot.value from 1 to 0..1 and add > constraints that it must not be empty for direct instances of > Slot and must > be empty for instances of DataSlot. In OCL: [on Slot] > self.oclIsTypeOf(Slot) > implies self.value->notEmpty() and [on DataSlot] > self.value->isEmpty(). > g) Update Figure 7-6-3 to change the 2 instances of Slot > associated with > the > 'name' Attribute to be instances of DataSlot, delete the > attached instances > of DataValue, and attach the 'value=' strings directly to the > DataSlots > making them 'dataValue='. > > Rationale > --------- > This is intended to be a minimal-impact proposal that is > incremental and > does not impact existing implementations. > It does not replace the existing DataValue class where there > is the real > need to have stand-alone managed data values (the equivalent > of Constant in > MOF and EnumerationLiteral in UML), but is for use where the > values are > pure > one-off values for which the overhead of a separate > ModelElement is not > justified: for example most numeric and string values. > The George and Martha example in Figure 7-6-3 illustrates the > distinction: > for the one-off names "George Washington" and "Martha Custis > Washington" > then the new DataSlot is used, but for the pseudo-enumeration values > associated with the MaritalStatus attribute ("Married", "Widowed", > "Divorced") then DataValue is still used: in particular > because some of the > values (e.g. "Divorced") are not yet associated with any actual Slot. > > The reference from DataSlot to DataType is optional in order > to support > minimal datavalue representations and those that do not put > an onus on > receiving applications to check the DataSlot DataType against that > associated with the Attribute. > > > Proposed resolution B > --------------------- > This is identical to the proposed resolution A except for > item c) which is > revised as follows: > c) Add reference 'dataType'[1] to DataType, description: "The > type of the > dataValue." > > Rationale > --------- > The reference from DataSlot to DataType is mandatory in order to: > 1)maintain consistency with DataValue, which has a mandatory reference > 'classifier' to DataType, > 2)maintain uniformity in XMI files (All DataSlot elements > have a dataType > attribute. With the > proposed resolution A, some DataSlot elements must have a dataType > attribute, while others > may or may not have a dataType attribute.) > 3)avoid conditional and additional processing (All DataSlots have a > dataType reference pointing to > the data type. With the proposed resolution A, some > DataSlots must have a > dataType reference > pointing to the data type, while other DataSlots may or may > not have a > dataType reference, in > the later case the data type must be indirectly derived through the > associated Attribute/ > StructuredFeature and its type reference.) > > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company.