Issue 4418: Clarify whether null instances are currently valid MOF values (mof-rtf) Source: DSTC (Dr. Stephen Crawley, nobody) Nature: Clarification Severity: Significant Summary: The JMI expert group has identified an anomaly in the MOF spec with respect to null instances of Classes. According to the IDL mapping, a null instance is a valid value for an Attribute or a Parameter; e.g. paragraph 2 of section 5.3.4. On the other hand, the Abstract mapping (Chapter 4) does not mention null at all. JMI needs to know if null is a valid value for a Class instance, in the general case. Resolution: see above Revised Text: In Section 4.2, insert the following bullet points into the respective bullet lists that contrast Classes and DataTypes: "* Null is a valid instance of an M2-level Class, though there are limitations on its use." "* Null is not a valid instance of an M2-level DataType." In Section 4.4, add the following sentence to list item 1. "The null Class instance is only equal to itself." In Section 4.5, add the following as the last two paragraphs: "The null instance of an M2-level Class has a conceptual identity that is distinct from other (non-null) instances. Null conceptually exists for ever in all Class extents, but it does not have attribute values and cannot be related to other Instances (or itself) by an Association link." "Note - While null is currently a valid Class instance, some technology mappings do not support it. Therefore it is inadvisable to rely on being able to use the null instance value in a technology neutral metamodel." In Section 4.9.2.1, add "... except for the respective null instances." to the end of the first sentence. In Section 4.9.2.2, add the following bullet point: "* A Link cannot connect a null Class instance to any other instance (including itself)." In Section 4.10.2, add the following sentence to list item 1. "(This restriction does not apply when "v1" is a null instance.)" In Section 4.11.2, add the following sentence: "Since the null instance of a Class is defined to notionally belong to all extents for the Class, the Composition Closure Rule does not apply to Attributes with null values." Actions taken: July 25, 2001: received issue December 3, 2001: closed issue Discussion: [Steve Crawley] The concept of a null instance in MOF has been disputed. The MOF 1.3 IDL mapping is clear about this. This (to me) implies that null instances are valid values across the entire MOF framework. In my opinion, the anomaly is best corrected by amending Chapter 4 to state that null is a valid instance value, and make consequent changes. [The alternative of saying that the null instance is only legal in IDL-based repository would be bad for interoperability.] Note: This approach says nothing about whether a null Attribute or Parameter value is meaningful in any given metamodel. It is up to the metamodeller to decide this. If necessary, Constraints can be added to Attributes, Parameters and so on to disallow meaningless nulls. Note: It is currently explicitly illegal to use a null instance value in Association links and References. This would not change. The short term solution is to make it clear the null is a valid Class instance value across the entire MOF framework ... not just in the IDLmapping. However, we will note metamodellers should not rely on this since some mappings may not support null instance values. Note: there is an issue to review support for null in a future revision. This resolution simply clarifies the status quo. End of Annotations:===== X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: issues@omg.org cc: mof-rtf@omg.org Subject: Clarify whether null instances are currently valid MOF values Mime-Version: 1.0 Date: Wed, 25 Jul 2001 09:38:05 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: D$h!!a8d!! cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 4418 - proposed resolution In-Reply-To: Message from "Baisley, Donald E" of "Tue, 07 Aug 2001 13:08:00 EST." Mime-Version: 1.0 Date: Wed, 08 Aug 2001 11:54:30 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: Zb;!!DWJe9W<2e9(jV!! > This proposal matter-of-factly puts null in every class. Does this mean I > cannot define a constraint that excludes null from a particular class? For > example, I would like a constraint saying a ModelElement is NOT EQUAL TO > NULL. Is that possible? Can the proposed text be written in a way that > would permit such a constraint? Such a Constraint is indeed possible. However, since there is nothing in the MOF spec that says >>how<< to express constraints on various things. Hence, I don't know where I would put such text. An OCL Constraint on a Class valued Attribute or Parameter can say that null cannot be used. Similarly, an OCL Constraint could apply to a CollectionType, StructureField or an AliasType. Finally, you could put a "global" constraint on the contents of a Package or Class extent. However, I'm not sure how you'd express this in OCL or how you'd go about enforcing it in practice. > I look forward to this mess being cleaned up in 1.5. Agreed. But as discussed elsewhere, making "null" illegal has non-trivial impact on the IDL mapping APIs. At the very least, some operations will raise exceptions where they didn't before. And there is a case for simplifying and regularising the APIs for [0..1] Attributes and References. > The proposed text, "... the Composition Closure Rule does not apply to > Attributes with null values" should rather say "... the Composition > Closure Rule does not apply to null instances." Strictly, the current wording is correct because null can only mean a null Class instance. However, your wording is clearer, and I'll use it. -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Issue 4418 - proposed resolution Date: Tue, 7 Aug 2001 13:08:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: +~5!!]HMe9bM7!!G6Oe9 This proposal matter-of-factly puts null in every class. Does this mean I cannot define a constraint that excludes null from a particular class? For example, I would like a constraint saying a ModelElement is NOT EQUAL TO NULL. Is that possible? Can the proposed text be written in a way that would permit such a constraint? I look forward to this mess being cleaned up in 1.5. The proposed text, "... the Composition Closure Rule does not apply to Attributes with null values" should rather say "... the Composition Closure Rule does not apply to null instances." Regards, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Tuesday, August 07, 2001 12:33 AM To: mof-rtf@omg.org Subject: Issue 4418 - proposed resolution Please comment on the following proposed resolution to 4418. We need to resolve this issue in MOF 1.4 to clarify the spec for the JMI team. > Title: Clarify whether null instances are currently valid MOF values > Summary: > The JMI expert group has identified an anomaly in the MOF spec with respect > to null instances of Classes. According to the IDL mapping, a null > instance is a valid value for an Attribute or a Parameter; > e.g. paragraph > 2 of section 5.3.4. On the other hand, the Abstract mapping > (Chapter 4) > does not mention null at all. JMI needs to know if null is a valid > value > for a Class instance, in the general case. Proposed resolution: The short term solution is to make it clear the null is a valid Class instance value across the entire MOF framework ... not just in the IDL mapping. However, we will note metamodellers should not rely on this since some mappings may not support null instance values. Note: there is an issue to review support for null in a future revision. This resolution simply clarifies the status quo. Resolution text: In Section 4.2, insert the following bullet points into the respective bullet lists that contrast Classes and DataTypes: "* Null is a valid instance of an M2-level Class, though there are limitations on its use." "* Null is not a valid instance of an M2-level DataType." In Section 4.4, add the following sentence to list item 1. "The null Class instance is only equal to itself." In Section 4.5, add the following as the last two paragraphs: "The null instance of an M2-level Class has a conceptual identity that is distinct from other (non-null) instances. Null conceptually exists for ever in all Class extents, but it does not have attribute values and cannot be related to other Instances (or itself) by an Association link." "Note - While null is currently a valid Class instance, some technology mappings do not support it. Therefore it is inadvisable to rely on being able to use the null instance value in a technology neutral metamodel." In Section 4.9.2.1, add "... except for the respective null instances." to the end of the first sentence. In Section 4.9.2.2, add the following bullet point: "* A Link cannot connect a null Class instance to any other instance (including itself)." In Section 4.10.2, add the following sentence to list item 1. "(This restriction does not apply when "v1" is a null instance.)" In Section 4.11.2, add the following sentence: "Since the null instance of a Class is defined to notionally belong to all extents for the Class, the Composition Closure Rule does not apply to Attributes with null values." Importance: Normal Subject: Re: Issue 4418 - proposed resolution To: Stephen Crawley Cc: mof-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Stephen Brodsky" Date: Tue, 7 Aug 2001 09:36:16 -0700 X-MIMETrack: Serialize by Router on D03NM039/03/M/IBM(Release 5.0.6 |December 14, 2000) at 08/07/2001 12:03:28 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: \aDe9/mWd9Gj6e9Vkl!! Steve, Can you clarify the relationship between set/unset and null (if any)? In many domains, set to null is different than unset. Presumably, there is no relationship between null and lower bound multiplicity of zero. In terms of using null for parameters, it seems that null should be valid for any parameter (at least for user defined functions). This would imply null is a valid instance of datatypes. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 Stephen Crawley on 08/07/2001 12:32:48 AM To: mof-rtf@omg.org cc: Subject: Issue 4418 - proposed resolution Please comment on the following proposed resolution to 4418. We need to resolve this issue in MOF 1.4 to clarify the spec for the JMI team. > Title: Clarify whether null instances are currently valid MOF values > Summary: > The JMI expert group has identified an anomaly in the MOF spec with respect > to null instances of Classes. According to the IDL mapping, a null > instance is a valid value for an Attribute or a Parameter; > e.g. paragraph > 2 of section 5.3.4. On the other hand, the Abstract mapping > (Chapter 4) > does not mention null at all. JMI needs to know if null is a valid > value > for a Class instance, in the general case. Proposed resolution: The short term solution is to make it clear the null is a valid Class instance value across the entire MOF framework ... not just in the IDL mapping. However, we will note metamodellers should not rely on this since some mappings may not support null instance values. Note: there is an issue to review support for null in a future revision. This resolution simply clarifies the status quo. Resolution text: In Section 4.2, insert the following bullet points into the respective bullet lists that contrast Classes and DataTypes: "* Null is a valid instance of an M2-level Class, though there are limitations on its use." "* Null is not a valid instance of an M2-level DataType." In Section 4.4, add the following sentence to list item 1. "The null Class instance is only equal to itself." In Section 4.5, add the following as the last two paragraphs: "The null instance of an M2-level Class has a conceptual identity that is distinct from other (non-null) instances. Null conceptually exists for ever in all Class extents, but it does not have attribute values and cannot be related to other Instances (or itself) by an Association link." "Note - While null is currently a valid Class instance, some technology mappings do not support it. Therefore it is inadvisable to rely on being able to use the null instance value in a technology neutral metamodel." In Section 4.9.2.1, add "... except for the respective null instances." to the end of the first sentence. In Section 4.9.2.2, add the following bullet point: "* A Link cannot connect a null Class instance to any other instance (including itself)." In Section 4.10.2, add the following sentence to list item 1. "(This restriction does not apply when "v1" is a null instance.)" In Section 4.11.2, add the following sentence: "Since the null instance of a Class is defined to notionally belong to all extents for the Class, the Composition Closure Rule does not apply to Attributes with null values." From: "Martin Matula" To: , "Stephen Crawley" References: <200108070732.f777Wk601704@piglet.dstc.edu.au> Subject: Re: Issue 4418 - proposed resolution Date: Tue, 7 Aug 2001 10:52:48 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >5Me995P!!-2I!!f=)!! I agree with the proposed resolution. Martin ----- Original Message ----- From: "Stephen Crawley" To: Sent: Tuesday, August 07, 2001 9:32 AM Subject: Issue 4418 - proposed resolution > > Please comment on the following proposed resolution to 4418. We >need to > resolve this issue in MOF 1.4 to clarify the spec for the JMI team. > > > Title: Clarify whether null instances are currently valid MOF >values > > Summary: > > The JMI expert group has identified an anomaly in the MOF spec >with respect > > to null instances of Classes. According to the IDL mapping, a >null > > instance is a valid value for an Attribute or a Parameter; e.g. paragraph > > 2 of section 5.3.4. On the other hand, the Abstract mapping >(Chapter 4) > > does not mention null at all. JMI needs to know if null is a >valid value > > for a Class instance, in the general case. > > Proposed resolution: > > The short term solution is to make it clear the null is a valid >Class > instance value across the entire MOF framework ... not just in the >IDL > mapping. However, we will note metamodellers should not rely on >this > since some mappings may not support null instance values. > > Note: there is an issue to review support for null in a future >revision. > This resolution simply clarifies the status quo. > > Resolution text: > > In Section 4.2, insert the following bullet points into the >respective > bullet lists that contrast Classes and DataTypes: > > "* Null is a valid instance of an M2-level Class, though there are > limitations on its use." > > "* Null is not a valid instance of an M2-level DataType." > > In Section 4.4, add the following sentence to list item 1. > > "The null Class instance is only equal to itself." > > In Section 4.5, add the following as the last two paragraphs: > > "The null instance of an M2-level Class has a conceptual identity >that > is distinct from other (non-null) instances. Null conceptually >exists f or > ever in all Class extents, but it does not have attribute values >and > cannot be related to other Instances (or itself) by an >Association link." > > "Note - While null is currently a valid Class instance, some >technology > mappings do not support it. Therefore it is inadvisable to rely >on being > able to use the null instance value in a technology neutral >metamodel." > > In Section 4.9.2.1, add "... except for the respective null >instances." to > the end of the first sentence. > > In Section 4.9.2.2, add the following bullet point: > > "* A Link cannot connect a null Class instance to any other >instance > (including itself)." > > In Section 4.10.2, add the following sentence to list item 1. > > "(This restriction does not apply when "v1" is a null instance.)" > > In Section 4.11.2, add the following sentence: > > "Since the null instance of a Class is defined to notionally >belong > to all extents for the Class, the Composition Closure Rule does >not > apply to Attributes with null values." > > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Issue 4418 - proposed resolution Mime-Version: 1.0 Date: Tue, 07 Aug 2001 17:32:48 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 5-jd9d#Wd9!?o!!FF4e9 Please comment on the following proposed resolution to 4418. We need to resolve this issue in MOF 1.4 to clarify the spec for the JMI team. > Title: Clarify whether null instances are currently valid MOF values > Summary: > The JMI expert group has identified an anomaly in the MOF spec with > respect > to null instances of Classes. According to the IDL mapping, a null > instance is a valid value for an Attribute or a Parameter; > e.g. paragraph > 2 of section 5.3.4. On the other hand, the Abstract mapping > (Chapter 4) > does not mention null at all. JMI needs to know if null is a valid > value > for a Class instance, in the general case. Proposed resolution: The short term solution is to make it clear the null is a valid Class instance value across the entire MOF framework ... not just in the IDL mapping. However, we will note metamodellers should not rely on this since some mappings may not support null instance values. Note: there is an issue to review support for null in a future revision. This resolution simply clarifies the status quo. Resolution text: In Section 4.2, insert the following bullet points into the respective bullet lists that contrast Classes and DataTypes: "* Null is a valid instance of an M2-level Class, though there are limitations on its use." "* Null is not a valid instance of an M2-level DataType." In Section 4.4, add the following sentence to list item 1. "The null Class instance is only equal to itself." In Section 4.5, add the following as the last two paragraphs: "The null instance of an M2-level Class has a conceptual identity that is distinct from other (non-null) instances. Null conceptually exists for ever in all Class extents, but it does not have attribute values and cannot be related to other Instances (or itself) by an Association link." "Note - While null is currently a valid Class instance, some technology mappings do not support it. Therefore it is inadvisable to rely on being able to use the null instance value in a technology neutral metamodel." In Section 4.9.2.1, add "... except for the respective null instances." to the end of the first sentence. In Section 4.9.2.2, add the following bullet point: "* A Link cannot connect a null Class instance to any other instance (including itself)." In Section 4.10.2, add the following sentence to list item 1. "(This restriction does not apply when "v1" is a null instance.)" In Section 4.11.2, add the following sentence: "Since the null instance of a Class is defined to notionally belong to all extents for the Class, the Composition Closure Rule does not apply to Attributes with null values." X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Baisley, Donald E" cc: Stephen Crawley , mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 4418 - proposed resolution In-Reply-To: Message from "Baisley, Donald E" of "Wed, 08 Aug 2001 12:33:08 EST." Mime-Version: 1.0 Date: Fri, 10 Aug 2001 07:02:53 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: -_-!!^46e92!Oe9=T?e9 > I can express the constraint easily in OCL. Here is an immediate constraint > for Model.ModelElement: self <> null. Fair enough. That would be a reasonable way to express this. > Perhaps we should add this > constraint to MOF 1.4. We can remove it when it becomes redundant > in MOF > 1.5. I don't think it is necessary to add a Constraint like this to the MOF 1.4 Model: * There are no Attributes in the MOF 1.4 Model whose type is a Class, either Model.ModelElement or anything else. * There are a small number of Operations which have "in" Parameters whose type is a Class. However, we haven't placed any Constraints on Operation Parameters in the past to specify preconditions (e.g. not null) on Parameter values. And in each case, the "null" case makes sense ... in a useless kind of way; e.g. Model.Namespace.findElementsWithType(null, ...) can return an empty set / list, because no model element can have no Class. -- Steve From: "Baisley, Donald E" To: Stephen Crawley Cc: mof-rtf@omg.org Subject: RE: Issue 4418 - proposed resolution Date: Wed, 8 Aug 2001 12:33:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: nOYd9)Mnd9BiS!!O53e9 I can express the constraint easily in OCL. Here is an immediate constraint for Model.ModelElement: self <> null. Perhaps we should add this constraint to MOF 1.4. We can remove it when it becomes redundant in MOF 1.5. Regards, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Tuesday, August 07, 2001 6:55 PM To: Baisley, Donald E Cc: mof-rtf@omg.org; crawley@dstc.edu.au Subject: Re: Issue 4418 - proposed resolution Importance: High > This proposal matter-of-factly puts null in every class. Does this mean I > cannot define a constraint that excludes null from a particular class? For > example, I would like a constraint saying a ModelElement is NOT EQUAL TO > NULL. Is that possible? Can the proposed text be written in a way that > would permit such a constraint? Such a Constraint is indeed possible. However, since there is nothing in the MOF spec that says >>how<< to express constraints on various things. Hence, I don't know where I would put such text. An OCL Constraint on a Class valued Attribute or Parameter can say that null cannot be used. Similarly, an OCL Constraint could apply to a CollectionType, StructureField or an AliasType. Finally, you could put a "global" constraint on the contents of a Package or Class extent. However, I'm not sure how you'd express this in OCL or how you'd go about enforcing it in practice. > I look forward to this mess being cleaned up in 1.5. Agreed. But as discussed elsewhere, making "null" illegal has non-trivial impact on the IDL mapping APIs. At the very least, some operations will raise exceptions where they didn't before. And there is a case for simplifying and regularising the APIs for [0..1] Attributes and References. > The proposed text, "... the Composition Closure Rule does not apply to > Attributes with null values" should rather say "... the Composition > Closure Rule does not apply to null instances." Strictly, the current wording is correct because null can only mean a null Class instance. However, your wording is clearer, and I'll use it. -- Steve