Issue 2198: Data types available to metamodels is restricted (mof-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: Summary: Data types available to metamodels is restricted. Additional text: Metamodels need to define and support a variety of datatypes beyond what is available though typecodes. This will be essential for the CWM submissions. Suggested solution: allow metamodels for data types. Resolution: see above Revised Text: Too large to describe here. Refer to separate documents on the DSTC's MOF 1.4 RTF web page. Errata: 1) In 3.3.11 (AliasType), delete the second paragraph. (Starts "It is anticipated ..."). This text is left over from version 1 of this resolution and is now meaningless. 2) In 3.3.27 (Constant), change the type of the 'value' Attribute from 'LiteralType' to 'String'. In the IDL below, change 'LiteralType' to 'wstring', in 3 places. Corrigenda to the Revised Text: These were posted after the ballot commenced, and being substantive, need to be voted on. 1) In order to clarify the intent on how standard PrimitiveType instances are recognized as such, insert into 3.9 (PrimitiveTypes) the following sentences. "Technology mappings shall recognize standard PrimitiveType instances based on their qualified names. Multiple PrimitiveType instances with the required qualified name are deemed to mean the same thing." [This should tie a loose end so that we can back out of the UUID tar pit.] 2) To make the MOF -> IDL mapping work, we need to make sure that StructureTypes contain AT LEAST ONE StructureField. We could make this an "IDL mapping precondition", but I think it is more sensible to make this a Constraint on the MOF Model. I therefore propose the following Constraint be added to StructureType: [C-XX] MustHaveFields -- "A StructureType must contain at least one StructureField.", evaluationPolicy: deferred, OCL: TBD. 3) For consistency, the StructureField class needs to be able to contain any Tags or Constraints on the field. Proposed correction: Add a row to the containment matrix Add a "Contains" heading for StructureType Add an OCL constraint to express the containment rule 4) In 5.6.3.1 through 4, the sypertype strings need to be described as "fully qualified identifiers for OMG IDL interface" ... not just "fully qualified IDL identifiers" 5) In 5.6.2.1, the substitute name doesn't need to a valid CORBA IDL identifier. Rather it needs to be a name that maps to a valid CORBA IDL identifier after Format1/2/3 rewriting and other name mangling. 6) Add text to 3.10.* and 5.3.1 to say how Constant values for the PrimitiveTypes and CorbaIdlTypes are encoded; i.e. the "value" field of Model::Constant ... which used to be Any and now is String (16 bits). * Boolean is "TRUE" or "FALSE" * Integer types are CORBA IDL integer literal syntax with optional leading '-' * Floating point types are CORBA IDL floating point literal syntax with optional leading '-'. * String types are unencoded. * Character types uare unencoded except that an NUL is represented by an empty string. (NUL not being an allowed in an PrimitiveType::String) Actions taken: November 6, 1998: received issue December 3, 2001: closed issue Discussion: Discussion: (crawley@dstc.edu.au) Stephen Brodsky's suggested solution "addresses" the easy part of the problem. In fact, the MOF already allows you to express arbitrary data type systems in a way that should sup-port CMW. The hard problem of supporting arbitrary data types in the MOF is how to do it so that the data types can be used at the M2 level. I've been scratching my head over this particular problem for more than 2 years now. Unless you make some serious restrictions, the prob-lem is (I believe) intractable! Proposed resolution: The easy problem probably doesn't need addressing at all. The hard problem should be addressed in a separate MOF-related RFP, if at all. Schedule a specific teleconference for this issue Implementation: Nothing to do. Done [KR] This is a short term resolution to this issue so that JMI can share the MOF 1.4 meta-model. The key points are: Change the way that meta-models are represented to be based on explicit modelling rather than TypeCodes and Anys Remove support for data types that are CORBA centric; e.g. Any, TypeCode, union, "external IDL types" Make support for unsigned types, long double, character types, 8-bit strings "CORBA specific". It is anticipated that MOF 2.0 RFP submissions will provide a more comprehensive solution to MOF data typing. End of Annotations:===== Return-Path: From: Stephen Brodsky To: , Subject: MOF RTF issue: data types Date: Fri, 6 Nov 1998 15:26:51 -0500 Source: IBM (Dr. Stephen Brodsky, sbrodsky@us.ibm.com) Nature: Revision Severity: Significant Summary: Data types available to metamodels is restricted. Additional text: Metamodels need to define and support a variety of datatypes beyond what is available though typecodes. This will be essential for the CWM submissions. Suggested solution: allow metamodels for data types. 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 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 2198: Data types available to metamodels is restricted (mof-rtf) Mime-Version: 1.0 Date: Fri, 06 Apr 2001 14:47:25 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: Ig@!!Q8g!!`lKd9d>Od9 At the MOF RTF meeting at Irvine, the following was resolved: "Assuming the JMI spec public review is available in time for the RTF to act, consider including the JMI DataTypes metamodel and the primitive data types package to the MOF. Also specify the mapping to CORBA IDL data types in the MOF to IDL mapping." (I acknowledge the caveats in the above. Obviously we need to wait until the JMI spec is published before we can make a final judgement on the applicability of JMI DataTypes to MOF.) Notwithstanding that, it is not clear that the intent of JMI DataTypes is to address issue 2198. My understanding is that JMI is trying to (progressively) move towards a meta-model in which data typing was technology neutral, and did not depend on CORBA-centric types like TypeCode and Any. (This is a good thing, IMO) If anything, it looks like the JMI approach will ultimately restrict the range of data types supported in meta-models, certainly in technology independent ones. On the face of it, this is the reverse of what issue 2198 is asking for. For instance, one of Steve Brodsky's examples was a meta-model that had an element (e.g. Attribute) with the SQL date type as its type. AFAIK, JMI wouldn't allow you to do this, because SQL date is not a JMI primitive type. But then again, I'm on the record as saying that issue 2198 is wrong headed, so I don't see this as a problem ;-). -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Issue #2198 and JMI Mime-Version: 1.0 Date: Fri, 01 Jun 2001 00:50:49 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: e[2!!%j\!!8;X!!"'Q!! Folks, As most of you are aware, there is a Java Community Process underway to develop a Java version / analog of MOF. While JMI is still under non-disclosure, one of the most significant things they are trying to do is to make the JMI data type system non-CORBA centric, and to minimise the dependency of JMI on CORBA's TypeCode and Any types. This is being done by: 1) Defining an extended meta-meta-model for JMI. This meta-meta-model is a Package that inherits from the MOF Model Package. The new Package defines a number of new sub-Classes of Model::DataType as the "JMI way" to represent data types. 2) Defining the JMI -> Java mapping such that a JMI implementation can (in effect) not support TypeCode values. But at the same time, the JMI meta-model API will still include the DataType.typeCode methods to aid MOF / JMI interoperability. 3) Defining mappings between MOF 1.3 data types and JMI data types at all levels; e.g. type abstractions, representations of types in meta-models, and representations of values. Details of this proposal are still to be finalised, but my interpretation is that the JMI Expert Group has agreed on this approach in principle. Co-members of the JMI Expert Group and the MOF RTF (including myself) are now proposing that the JMI data type work should be incorporated into MOF 1.4 ... as a resolution to MOF RTF Issue #2198 More specifically, we are proposing that: 1) The JMI meta-meta-model (i.e. the new Package with the new sub-Classes of DataType) be "rebadged" as the MOF 1.4 "extended" meta-meta-model. 2) A couple of the Constraints in the MOF Model may be slightly modified to accomodate the extensions. (Details need to be sorted out.) 3) The MOF Model's use of "external IDL types" from the Reflective module should be replaced with data types defined in the Model Package. Since the JMI data type system does not support "external IDL types", this will improve JMI <-> MOF interoperability. In the MOF context, we would anticipate that every instance of DataType or a sub-Class of DataType would have a TypeCode that describes the type. In the case of a sub-Class of DataType, the 'typeCode' Attribute would need to match the type details expressed in the Class. For example, a PrimitiveType's 'typeCode' would need to match its 'name'. [Since details of the JMI data types are still a bit fluid, the next bit is subject to change.] The JMI data types are currently as follows: * PrimitiveType has a 'name' field that specifies the particular primitive data types. The set of primitive data types supported by JMI is still to be finalised. The last JMI draft list them as (if I recall correctly): Boolean, Character, String, Byte, Short, Integer, Long, Float, Double, Any and TypeCode but there has also been discussion of reducing the list to: Boolean, String, Integer and Real * StructType contains Attribute elements that represent struct fields. * EnumType has a 'labels' attribute that contains the list of enumerator names. * CollectionType has an attribute that gives the upper limit on the collection size. * AliasType is equivalent to a tk_alias. Note that the representation of data types in DataType sub-Classes is less than 100% (if you ignore the 'typeCode' Attribute). There are mismatches involving signed / unsigned numbers, and 8 versus 16 bit characters. CollectionTypes don't precisely match arrays and sequences. IDL external types, non-composite Class types, and union types are not expressible. In the MOF 1.4 context, we can represent all MOF data types using the 'typeCode' Attribute and (in some cases) instances of DataType. However, a JMI server may not be capable of doing this because a JMI server would be "allowed" to drop TypeCode information. When meta-models is moved between MOF and JMI worlds, the following mappings would need to take place. * MOF 1.4 (extended) meta-models -> JMI: No translation is necessary. * MOF 1.3 meta-models -> JMI: Map instances of DataType to instances of the corresponding sub-Classes of DataType. * JMI meta-models -> MOF 1.4 (extended): Synthesize TypeCodes (and TypeAliases) and add to instances of sub-Classes of DataType * JMI meta-models -> MOF 1.3: Synthesize TypeCodes (and TypeAliases) and convert instance of sub-Classes of DataType to instances of DataType. It is clear that round-tripping some MOF meta-models from MOF to a "pure" JMI server and back will lose some data type information. It is also clear that a MOF IDL generator cannot (in all cases) use a "pure" JMI server. Fortunately, most meta-models use simple data types and will be largely immune to this. [At least, that is what we believe.] If this is a significant problem, there are a couple of options: * Map MOF data types to JMI DataTypes with Constraints. For example, a MOF 'octet' could map to a JMI 'Integer' with a Constraint that limits its value to 0 through 255. The Constraint could be expressed in a way that doesn't require the JMI server to implement a Constraint language. * Map MOF data types to JMI DataTypes with Constraints. For example, a MOF 'octet' could map to a JMI 'Integer' with a Tag with tagId (say) "idl type" and value (say) "octet". -- Steve From: "Iyengar, Sridhar" To: Stephen Crawley , mof-rtf@omg.org Subject: RE: Issue #2198 and JMI Date: Thu, 31 May 2001 11:01:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 5bGe9"ji!!c&H!!&Nbd9 I just wanted the mof-rtf team to know that more details about this will be forthcoming after the Java One conference (next week) and that the steps 1-3 identified by Steve is one of the approaches being considered and that it is not finalized (as he himself indicates further down in the note) Be there at the call later today. Sridhar ------------------------------------------------------------------------ ---- Sridhar Iyengar Unisys Fellow, Director of Advanced Technology 25725, Jeronimo Road Mission Viejo, CA 92691 E-mail : Sridhar.iyengar2@unisys.com Phone : 949-380-5692 Fax : 949-380-6632 ------------------------------------------------------------------------ -------------- > -----Original Message----- > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > Sent: Thursday, May 31, 2001 7:51 AM > To: mof-rtf@omg.org > Subject: Issue #2198 and JMI > > > > Folks, > > As most of you are aware, there is a Java Community Process underway > to develop a Java version / analog of MOF. While JMI is still under > non-disclosure, one of the most significant things they are trying > to do is to make the JMI data type system non-CORBA centric, and to > minimise the dependency of JMI on CORBA's TypeCode and Any types. > > This is being done by: > > 1) Defining an extended meta-meta-model for JMI. This > meta-meta-model > is a Package that inherits from the MOF Model Package. The new > Package defines a number of new sub-Classes of > Model::DataType as > the "JMI way" to represent data types. > > 2) Defining the JMI -> Java mapping such that a JMI > implementation can > (in effect) not support TypeCode values. But at the > same time, the > JMI meta-model API will still include the > DataType.typeCode methods > to aid MOF / JMI interoperability. > > 3) Defining mappings between MOF 1.3 data types and JMI data types > at all levels; e.g. type abstractions, representations of types > in meta-models, and representations of values. > > Details of this proposal are still to be finalised, but my > interpretation > is that the JMI Expert Group has agreed on this approach in principle. > > Co-members of the JMI Expert Group and the MOF RTF (including myself) > are now proposing that the JMI data type work should be incorporated > into MOF 1.4 ... as a resolution to MOF RTF Issue #2198 > > More specifically, we are proposing that: > > 1) The JMI meta-meta-model (i.e. the new Package with the > new sub-Classes > of DataType) be "rebadged" as the MOF 1.4 "extended" > meta-meta-model. > > 2) A couple of the Constraints in the MOF Model may be > slightly modified > to accomodate the extensions. (Details need to be sorted out.) > > 3) The MOF Model's use of "external IDL types" from the Reflective > module should be replaced with data types defined in > the Model Package. > Since the JMI data type system does not support > "external IDL types", > this will improve JMI <-> MOF interoperability. > > In the MOF context, we would anticipate that every instance > of DataType > or a sub-Class of DataType would have a TypeCode that describes the > type. In the case of a sub-Class of DataType, the 'typeCode' Attribute > would need to match the type details expressed in the Class. For > example, a PrimitiveType's 'typeCode' would need to match its 'name'. > > [Since details of the JMI data types are still a bit fluid, the next > bit is subject to change.] > > The JMI data types are currently as follows: > > * PrimitiveType has a 'name' field that specifies the particular > primitive data types. The set of primitive data types supported > by JMI is still to be finalised. The last JMI draft list them as > (if I recall correctly): > > Boolean, Character, String, Byte, Short, Integer, Long, > Float, Double, Any and TypeCode > > but there has also been discussion of reducing the list to: > > Boolean, String, Integer and Real > > * StructType contains Attribute elements that represent > struct fields. > > * EnumType has a 'labels' attribute that contains the list > of enumerator names. > > * CollectionType has an attribute that gives the upper limit on the > collection size. > > * AliasType is equivalent to a tk_alias. > > Note that the representation of data types in DataType sub-Classes is > less than 100% (if you ignore the 'typeCode' Attribute). There are > mismatches involving signed / unsigned numbers, and 8 versus 16 bit > characters. CollectionTypes don't precisely match arrays and > sequences. > IDL external types, non-composite Class types, and union types are not > expressible. > > In the MOF 1.4 context, we can represent all MOF data types using the > 'typeCode' Attribute and (in some cases) instances of > DataType. However, > a JMI server may not be capable of doing this because a JMI > server would > be "allowed" to drop TypeCode information. > > When meta-models is moved between MOF and JMI worlds, the following > mappings would need to take place. > > * MOF 1.4 (extended) meta-models -> JMI: No translation > is necessary. > > * MOF 1.3 meta-models -> JMI: Map instances of DataType > to instances > of the corresponding sub-Classes of DataType. > > * JMI meta-models -> MOF 1.4 (extended): Synthesize TypeCodes (and > TypeAliases) and add to instances of sub-Classes of DataType > > * JMI meta-models -> MOF 1.3: Synthesize TypeCodes (and > TypeAliases) and convert instance of sub-Classes of DataType to > instances of DataType. > > It is clear that round-tripping some MOF meta-models from MOF to a > "pure" JMI server and back will lose some data type > information. It is > also clear that a MOF IDL generator cannot (in all cases) use a "pure" > JMI server. Fortunately, most meta-models use simple data types and > will be largely immune to this. [At least, that is what we believe.] > > If this is a significant problem, there are a couple of options: > > * Map MOF data types to JMI DataTypes with Constraints. > For example, > a MOF 'octet' could map to a JMI 'Integer' with a Constraint > that limits its value to 0 through 255. The Constraint could be > expressed in a way that doesn't require the JMI server > to implement > a Constraint language. > > * Map MOF data types to JMI DataTypes with Constraints. > For example, > a MOF 'octet' could map to a JMI 'Integer' with a Tag with tagId > (say) "idl type" and value (say) "octet". > > -- Steve > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org, Ravi Dirckze cc: "Baisley, Donald E" Subject: Should we allow Class to be used in DataTypes? Mime-Version: 1.0 Date: Tue, 19 Jun 2001 12:12: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: VR)!!]>%"!U7#"!g?ad9 CollectionTypes have a base type that could in theory be any Classifier. Associations don't make much sense as the base type of a collection data type, but DataTypes do, and so do Classes ... in a sense. In MOF 1.3, we allowed an array or sequence DataType to have a Class as a base type, albeit with the restriction that the elements of the array or sequence are treated as pure object references; i.e. not components. However, I'm not sure if we should allow this in MOF 1.4. The need to distinguish between component and non-component objects is in core MOF would (IMO) make them unnecessarily technology specific. At the very least, it complicates things for technologies (like Java) where you typically don't need to worry about object life-cycle semantics. The same question arises for the 'type' of an AliasType and the 'type' of a StructureField. I propose that we disallow using Class as the 'type' (i.e. base type) of an AliasType, CollectionType or StructureField. We could even disallow Class as the 'type' of Attribute, but that might be going a bit far. What do other people think about this? Should we do it now, or leave this for MOF 2.0 submissions? -- Steve X-Sender: riehle@ice.inf.ethz.ch X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 18 Jun 2001 23:11:56 -0400 To: Stephen Crawley , mof-rtf@omg.org, Ravi Dirckze From: Dirk Riehle Subject: Re: Should we allow Class to be used in DataTypes? Cc: "Baisley, Donald E" In-Reply-To: <200106190212.f5J2Cf614156@piglet.dstc.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: H8%!!oE6!!LI"e9Jj cc: Stephen Crawley , mof-rtf@omg.org, Ravi Dirckze , "Baisley, Donald E" , crawley@dstc.edu.au Subject: Re: Should we allow Class to be used in DataTypes? In-Reply-To: Message from Dirk Riehle of "Mon, 18 Jun 2001 23:11:56 -0400." <5.0.2.1.2.20010618230821.024f8578@ice.inf.ethz.ch> Mime-Version: 1.0 Date: Wed, 20 Jun 2001 15:26:10 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: gpNe9OFHe9BE7!!A@ >I propose that we disallow using Class as the 'type' (i.e. base type) of > >an AliasType, CollectionType or StructureField. We could even disallow > >Class as the 'type' of Attribute, but that might be going a bit far. > > One of the restrictions in our (UML) implementation is exactly that: an > Attribute may have only a DataType as type (rather than Classifier). While > this causes some problems when reading in arbitrary models from XMI, the > general advantages are so big that we are very happy with this decision. I > guess it easily transfers to MOF. I've run into a snag. The 'verify' operation on Model::ModelElement has an 'out' parameter whose base type is a struct with field 'elementInError' whose type needs to be Model::ModelElement! (In MOF 1.3 its type is Reflective::RefObject ... but that's an IDL type.) Should we allow data type fields (etc) to have a Class type when the data type is used as a parameter type? (Yuck!) Should we remove the 'verify' operation from ModelElement and make it an operation in the (implementation technology specific) reflective layer; e.g. in IDL it would be an operation on the RefBaseObject interface. (I like this, because means that all meta-objects could have an API for invoking constraint validation!) Comments / suggestions please! -- Steve From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Should we allow Class to be used in DataTypes? Date: Wed, 20 Jun 2001 13:04:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /KJe9:T%e9MY[d9SjQ!! Hi Steve and Dirk, First, we should move the verify operation to the reflective layer. Verification makes sense at the level of RefBaseObject. Constraints can be applied to any MOF objects or to extents, so verification makes sense for any of these. Second, we know that MOF instances of a class are handled by reference and instances of a data type are handled by value. There is no problem using a class type within a collection type or a structure type. A collection or structure instance will only contain references to objects. There are no composition semantics here. A structure member should not be confused with an attribute. We clearly need to define a separate specialization of StructuralFeature for structure member. Regards, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Tuesday, June 19, 2001 10:26 PM To: Dirk Riehle Cc: Stephen Crawley; mof-rtf@omg.org; Ravi Dirckze; Baisley, Donald E; crawley@dstc.edu.au Subject: Re: Should we allow Class to be used in DataTypes? > >I propose that we disallow using Class as the 'type' (i.e. base type) of > >an AliasType, CollectionType or StructureField. We could even disallow > >Class as the 'type' of Attribute, but that might be going a bit far. > > One of the restrictions in our (UML) implementation is exactly that: an > Attribute may have only a DataType as type (rather than Classifier). While > this causes some problems when reading in arbitrary models from XMI, the > general advantages are so big that we are very happy with this decision. I > guess it easily transfers to MOF. I've run into a snag. The 'verify' operation on Model::ModelElement has an 'out' parameter whose base type is a struct with field 'elementInError' whose type needs to be Model::ModelElement! (In MOF 1.3 its type is Reflective::RefObject ... but that's an IDL type.) Should we allow data type fields (etc) to have a Class type when the data type is used as a parameter type? (Yuck!) Should we remove the 'verify' operation from ModelElement and make it an operation in the (implementation technology specific) reflective layer; e.g. in IDL it would be an operation on the RefBaseObject interface. (I like this, because means that all meta-objects could have an API for invoking constraint validation!) Comments / suggestions please! -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Juergen Boldt Subject: Re: Should we allow Class to be used in DataTypes? In-reply-to: Your message of "Wed, 20 Jun 2001 12:13:09 -0400." <4.3.2.7.2.20010620121252.00e50790@emerald.omg.org> Mime-Version: 1.0 Date: Thu, 21 Jun 2001 09:14:43 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: eaO!!N=Je92a"!!ZQ7!! Juergen, That's correct ... this is discussion of the proposed resolution to an existing issue. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Baisley, Donald E" cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Should we allow Class to be used in DataTypes? In-Reply-To: Message from "Baisley, Donald E" of "Wed, 20 Jun 2001 13:04:38 EST." Mime-Version: 1.0 Date: Thu, 21 Jun 2001 10:41:26 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: \j1!!+ead9Qb9e9B#De9 > Hi Steve and Dirk, > > First, we should move the verify operation to the reflective layer. > Verification makes sense at the level of RefBaseObject. Constraints > can be > applied to any MOF objects or to extents, so verification makes > sense for > any of these. I'll do this. I think we've already got an issue on this anyway, so I'll work up a resolution. > Second, we know that MOF instances of a class are handled by reference and > instances of a data type are handled by value. There is no problem using a > class type within a collection type or a structure type. A collection or > structure instance will only contain references to objects. There are no > composition semantics here. A structure member should not be confused with > an attribute. I don't think it is as clear-cut as this. In the IDL mapping, Class instances (objects) ARE passed as references and DataType instances (values) ARE passed as value. But this need not be the case in other mappings. For example, in XMI Class instances are passed by value, and in JMI we haven't finally decided if data values are (in effect) passed as references or as values. The MOF "Abstract Mapping" says that the difference between Class and DataType instances is that the former have "identity" and the latter don't. My line of thinking was that aggregation semantics don't make sense in an abstract meta-model. This is because, aggregation semantics are (almost) entirely about specifying object life-cycle behaviour. This should not be the concern of an abstract (i.e. technology neutral) meta-model. But I think I've gone too far. So I withdraw my proposal of forbidding the use of Classes within DataTypes. > We clearly need to define a separate specialization of > StructuralFeature for structure member. Not of StructuralFeature. StructuralFeature has 'visibility', 'scope', 'multiplicity' and 'isChangeable' attributes, and (IMO) we don't want the complexity of any of these. (Especially since CollectionType now has a 'multiplicity' attribute!) I've been assuming that StructureField should be a specialisation of TypedElement. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Draft of DataType changes. Mime-Version: 1.0 Date: Thu, 21 Jun 2001 15:48: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: B;@!!>am!!9!Ne9TJ"!! Folks, I'm just about to put excerpted draft versions of the new Chapters 3 & 4 of the MOF spec onto the MOF RTF web page at: http://www.dstc.com/MOF/rtf1.4/ These show the changes and additions needed to do data typing the new way. There are other changes needed in other Chapters too. I'm working on it ... Ravi and Don have commented on an earlier version of the Chapter 3 changes. But I've done a lot more since then, so I won't claim that they necessarily endorse this snapshot. -- Steve ~ From: "Martin Matula" To: "Baisley, Donald E" , "Stephen Crawley" Cc: , References: <200106210041.f5L0fE602235@piglet.dstc.edu.au> Subject: Re: Should we allow Class to be used in DataTypes? Date: Thu, 21 Jun 2001 13:29:15 +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: =6bd92"@!!R3 > Hi Steve and Dirk, > > > > First, we should move the verify operation to the reflective > >layer. > > Verification makes sense at the level of RefBaseObject. > >Constraints can be > > applied to any MOF objects or to extents, so verification makes > >sense for > > any of these. > > I'll do this. I think we've already got an issue on this anyway, so > >I'll > work up a resolution. I also vote for removing ModelElement.verify and adding verify into RefBaseObject. > Not of StructuralFeature. StructuralFeature has 'visibility', 'scope', > 'multiplicity' and 'isChangeable' attributes, and (IMO) we don't want > the complexity of any of these. (Especially since CollectionType now > has a 'multiplicity' attribute!) > > I've been assuming that StructureField should be a specialisation of > TypedElement. I agree - visibility, scope and isChangeable are not applicable for structure fields. However, I am not convinced, that it is useful to have CollectionType and use it instead of multiplicity attribute for fields. I would skip CollectionType - I don't think it is needed. Martin From: Jeffrey Mischkinsky Message-Id: <200106211610.JAA26050@wheel.dcn.davis.ca.us> Subject: Re: Draft of DataType changes. To: crawley@dstc.edu.au (Stephen Crawley) Date: Thu, 21 Jun 2001 09:10:32 -0700 (PDT) Cc: mof-rtf@omg.org In-Reply-To: <200106210548.f5L5mP604010@piglet.dstc.edu.au> from "Stephen Crawley" at Jun 21, 2001 03:48:37 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: g"Vd9CQpd9P~5e9lIp!! 'Stephen Crawley' writes: > > > Folks, > > I'm just about to put excerpted draft versions of the new Chapters 3 & 4 of > the MOF spec onto the MOF RTF web page at: > > http://www.dstc.com/MOF/rtf1.4/ It doesn't appear that the pdf for Chapter 3 is really there. jeff > > These show the changes and additions needed to do data typing the > new > way. There are other changes needed in other Chapters too. I'm > working > on it ... > > Ravi and Don have commented on an earlier version of the Chapter 3 > changes. But I've done a lot more since then, so I won't claim that > they necessarily endorse this snapshot. > > -- Steve > > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jeffrey Mischkinsky cc: crawley@dstc.edu.au (Stephen Crawley), mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Draft of DataType changes. In-Reply-To: Message from Jeffrey Mischkinsky of "Thu, 21 Jun 2001 09:10:32 MST." <200106211610.JAA26050@wheel.dcn.davis.ca.us> Mime-Version: 1.0 Date: Fri, 22 Jun 2001 06:59:59 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: \68!!GKm!!:6id9`iM!! > > I'm just about to put excerpted draft versions of the new Chapters 3 & 4 of > > the MOF spec onto the MOF RTF web page at: > > > > http://www.dstc.com/MOF/rtf1.4/ > > It doesn't appear that the pdf for Chapter 3 is really there. Sorry ... fixed. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Chapter 3 data type changes In-Reply-To: Message from "Dirckze, Ravi" of "Thu, 21 Jun 2001 15:16:40 EST." Mime-Version: 1.0 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Date: Fri, 22 Jun 2001 13:38:15 +1000 Sender: crawley@dstc.edu.au Content-Type: text/plain; charset=us-ascii X-UIDL: ;*(e9-5T!!2l$"!h of "Thu, 21 Jun 2001 15:16:40 EST." Mime-Version: 1.0 Date: Fri, 22 Jun 2001 14:19:13 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: (N4e9jUnd9p"1e9E#'e9 Compromise proposal on MOF primitive / builtin data types. 1) PrimitiveTypes package as before. 2) The package contains 4 standard PrimitiveType instances as before, with names "Boolean", "UniversalString", "UniversalInteger" and "UniversalFloat". Semantics are as before; i.e. "UniversalInteger" is the infinite set of all integers, etc. 3) Maybe ... define a text encoding for each of the "Universal" types, and recommend that these types map to string, unless a technology has a better alternative. If XMI supports the encoding, we've at least got a way to interchange values for data types that is not mapped to other technologies. 4) The package contains 3 standard AliasType instances called: Integer - with constraint limiting to -2**31 to 2**31 - 1 Float - IEEE single precision floating point String - UTF16 string (no NUL) 5) There is an additional Package called ExtendedDataTypes that contains instances for a range of useful data types, appropriately named and constrained. Support for this Package in any mapping is OPTIONAL. Therefore, usage makes a meta-model technology specific. Possible elements include: Integer8, Integer16, Integer32, Integer64, ( Integer128, ... ) Unsigned8, Unsigned16, Unsigned32, Unsigned64, ( Unsigned128, ... ) (Integer7, Integer15, Integer31, Integer63, Integer127, ... ) Float64, (Float96, ...) StringUTF16, (StringASCII, ...) CharUTF16, (...) Date - e.g. subtype of IntegerXYZ denoting seconds (or whatever) before / after some well-known date?? I'm open to suggestions for additions / deletions, but my key point is that the alias types should be available, so that meta-models denote a range of useful primitive data types in a standard way. Martin: unfortunately, I don't think we can require MOF implementations to map to data types based on an analysis of an attached Constraint's expression string. There is nothing stopping a MOF implementation from doing this, but making this mandatory presents too much of a burden on implementors. Especially because there is little enthusiasm for having lots of data types in the first place! -- Steve From: "Martin Matula" To: , References: <200106220338.f5M3c2617944@piglet.dstc.edu.au> Subject: Re: Chapter 3 data type changes Date: Fri, 22 Jun 2001 15:25:02 +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: 3Bdd9Z^5e9elCe9-@Nd9 Hi Steve, > Concerning 3). If we define (say) MOF's primitive integer type to > have a fixed range, it makes it impossible to define larger integer > types that are theoretically well-founded in the context of the MOF > spec: MOF is a language. It is possible to add new primitive types to it in the same way as it is possible in any other language. If there will be times when people will need 128-bit integer in Java or C++, there is no other way of adding it than adding a new primitive type. The same thing we can do in MOF. I think it is much better to add types when there is enough demand for them, than create a huge and too granular set of types in the beginning by trying to cover all possibilities (you will always miss some type anyway), and then in future revision removing those types that are useless. When we will add too many types in the beginning, how will we get rid of them later if it will show up that they are not needed and counterproductive? Martin X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Martin Matula" cc: mof-rtf@omg.org, crawley@dstc.edu.au, crawley@dstc.edu.au Subject: Re: Chapter 3 data type changes In-Reply-To: Message from "Martin Matula" of "Fri, 22 Jun 2001 15:25:02 +0200." <086701c0fb1e$be466910$844b9c81@matula> Mime-Version: 1.0 Date: Sat, 23 Jun 2001 00:54:31 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: I\Pd959Zd9IJ(e9=3L!! Martin, > > Concerning 3). If we define (say) MOF's primitive integer type to > > have a fixed range, it makes it impossible to define larger > > integer > > types that are theoretically well-founded in the context of the > > MOF > > spec: > > MOF is a language. It is possible to add new primitive types to it > > in the > same way as it is possible in any other language. If there will be > > times > when people will need 128-bit integer in Java or C++, there is no > > other way > of adding it than adding a new primitive type. The same thing we can > > do in > MOF. In my view, this won't happen. If I lose this debate, there will be too much resistance from various people to reopening it in the forseeable future. Not least because the same debate will need to be reopened in the JMI space as well. It is more likely that, if the set of primitive types is too limitted, some vendors will define non-standard primitive types as a "value added" feature. I'd have no qualms about doing this myself. -- Steve Date: Fri, 22 Jun 2001 14:35:20 -0400 From: Peter Denno X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Crawley CC: Martin Matula , mof-rtf@omg.org Subject: Re: Chapter 3 data type changes References: <200106221454.f5MEsI606182@piglet.dstc.edu.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Martin, > > > > Concerning 3). If we define (say) MOF's primitive integer type >to > > > have a fixed range, it makes it impossible to define larger >integer > > > types that are theoretically well-founded in the context of the >MOF > > > spec: > > > > MOF is a language. It is possible to add new primitive types to it >in the > > same way as it is possible in any other language. If there will be >times > > when people will need 128-bit integer in Java or C++, there is no >other way > > of adding it than adding a new primitive type. The same thing we >can do in > > MOF. > > In my view, this won't happen. If I lose this debate, there will be >too > much resistance from various people to reopening it in the >forseeable > future. Not least because the same debate will need to be reopened >in > the JMI space as well. > > It is more likely that, if the set of primitive types is too >limitted, > some vendors will define non-standard primitive types as a "value >added" > feature. I'd have no qualms about doing this myself. > > -- Steve -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8260 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8260 FAX: +1 301-975-4694 From: "Martin Matula" To: "Peter Denno" , "Stephen Crawley" Cc: References: <200106221454.f5MEsI606182@piglet.dstc.edu.au> <3B338FE8.20DBDF39@nist.gov> Subject: Re: Chapter 3 data type changes Date: Fri, 22 Jun 2001 21:04:27 +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: %4O!!G7d!!(B-!!WW/!! Peter, I would agree with you, if there would be a way for an implementation to determine, what is a range for the specified alias. However, as I understand it, MOF RTF has decided not to do it so, because it would be too complicated - it would require creating some subset of OCL. As you could notify, Steve's proposal is relying on identity of each alias, which means that adding a new alias (unknown for existing MOF implementations) is almost equal to adding a new primitive type... If that would not be a case, why would we need so many pre-defined aliases? One could define aliases that he wants to use in his metamodel and other implementations would recognize it. That would be cool. But saying that we are reducing set of primitive types and at the same time we are simulating (in fact trying to bring back) all of the old primitive types by aliases is somehow strange and I don't like it. I doubt that is what was meant by reducing set of primitive types... Martin ----- Original Message ----- From: "Peter Denno" To: "Stephen Crawley" Cc: "Martin Matula" ; Sent: Friday, June 22, 2001 8:35 PM Subject: Re: Chapter 3 data type changes > Martin, > > I, for one, do not want to have to negotiate with the MOF RTF just >to add a > primitive datatype. > > I generally support the changes to chapters 3 and 4 that Steve >proposes. The > approach is an orderly means to extend the primitive datatypes. > > Though the changes do not go far enough to enable the MOF to >represent the > datatyping mechanism of schema I would like to represent in M2 >meta-models (ISO > Express schema), (and probably the same could be said for other information > modeling and relational modeling technology) it is a step towards a >more widely > applicable MOF (at what I'd guess is a small cost). > > I think we should look further at subtyping of datatypes (and more broadly, use > cases for MOF) in MOF 2.0. > > > Stephen Crawley wrote: > > > Martin, > > > > > > Concerning 3). If we define (say) MOF's primitive integer >type to > > > > have a fixed range, it makes it impossible to define larger >integer > > > > types that are theoretically well-founded in the context of >the MOF > > > > spec: > > > > > > MOF is a language. It is possible to add new primitive types to >it in the > > > same way as it is possible in any other language. If there will >be times > > > when people will need 128-bit integer in Java or C++, there is >no other way > > > of adding it than adding a new primitive type. The same thing we >can do in > > > MOF. > > > > In my view, this won't happen. If I lose this debate, there will >be too > > much resistance from various people to reopening it in the >forseeable > > future. Not least because the same debate will need to be >reopened in > > the JMI space as well. > > > > It is more likely that, if the set of primitive types is too >limitted, > > some vendors will define non-standard primitive types as a "value >added" > > feature. I'd have no qualms about doing this myself. > > > > -- Steve > > -- > Best Regards, > - Peter > > Peter Denno > National Institute of Standards and Technology, > Manufacturing System Integration Division, > 100 Bureau Drive, Mail Stop 8260 Tel: +1 301-975-3595 > Gaithersburg, MD, USA 20899-8260 FAX: +1 301-975-4694 > > From: "Dirckze, Ravi" To: Stephen Crawley , mof-rtf@omg.org Subject: RE: Chapter 3 data type changes Date: Fri, 22 Jun 2001 21:01:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: TM0!!OP,e9F]K!!FCbd9 I for one, tend to agree with Martin's comment (from his subsequent e-mail) about defining a minimal subset and adding more types when there is sufficient demand for them. I also think that Steve's proposal is an interesting compromise. I would like to propose a slight modification to Steve's proposal here: 1. Define a PrimitiveTypes package as part of the core specification that contains 4 standard PrimitiveType instances as before, with names "Boolean", "String", "Integer" and "Float" (you can even call it "UnivarsalInteger", etc.). Define a *default* mapping (or recommended mapping) for these types as follows: > Integer - with constraint limiting to -2**31 to 2**31 - 1 > Float - IEEE single precision floating point > String - UTF16 string (no NUL) 3) define an *optional* Package called ExtendedDataTypes that that contains instances for Integer32, Float32, UTF16String, and whatever else is thought of as common data types used for metamodeling. Cheers, Ravi Dirckze, PhD. ravi.dirckze@unisys.com 949/380-4907 > -----Original Message----- > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > Sent: Thursday, June 21, 2001 9:19 PM > To: mof-rtf@omg.org; crawley@dstc.edu.au > Subject: Re: Chapter 3 data type changes > > > > Compromise proposal on MOF primitive / builtin data types. > > 1) PrimitiveTypes package as before. > > 2) The package contains 4 standard PrimitiveType instances as before, > with names "Boolean", "UniversalString", "UniversalInteger" > and "UniversalFloat". Semantics are as before; i.e. > "UniversalInteger" > is the infinite set of all integers, etc. > > 3) Maybe ... define a text encoding for each of the > "Universal" types, > and recommend that these types map to string, unless a > technology has > a better alternative. If XMI supports the encoding, > we've at least > got a way to interchange values for data types that is not mapped > to other technologies. > > 4) The package contains 3 standard AliasType instances called: > > Integer - with constraint limiting to -2**31 to 2**31 - 1 > Float - IEEE single precision floating point > String - UTF16 string (no NUL) > > 5) There is an additional Package called ExtendedDataTypes that > contains instances for a range of useful data types, appropriately > named and constrained. > > Support for this Package in any mapping is OPTIONAL. Therefore, > usage makes a meta-model technology specific. > > Possible elements include: > > Integer8, Integer16, Integer32, Integer64, ( Integer128, ... ) > Unsigned8, Unsigned16, Unsigned32, Unsigned64, ( > Unsigned128, ... ) > (Integer7, Integer15, Integer31, Integer63, Integer127, ... ) > Float64, (Float96, ...) > StringUTF16, (StringASCII, ...) > CharUTF16, (...) > > Date - e.g. subtype of IntegerXYZ denoting seconds (or > whatever) > before / after some well-known date?? > > I'm open to suggestions for additions / deletions, but my key point > is that the alias types should be available, so that meta-models > denote a range of useful primitive data types in a standard way. > > Martin: unfortunately, I don't think we can require MOF > implementations > to map to data types based on an analysis of an attached Constraint's > expression string. There is nothing stopping a MOF > implementation from > doing this, but making this mandatory presents too much of a burden on > implementors. Especially because there is little enthusiasm > for having > lots of data types in the first place! > > -- Steve > From: "Martin Matula" To: "Dirckze, Ravi" , "Stephen Crawley" , References: Subject: Re: Chapter 3 data type changes Date: Sat, 23 Jun 2001 13:30:38 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: A`$e9HI(e9BCB!![-A!! Hi Ravi, > 3) define an *optional* Package called ExtendedDataTypes that that contains > instances for Integer32, Float32, UTF16String, and whatever else is thought > of as common data types used for metamodeling. When I am reading these lines it is not clear to me, whether you agree, that mappings should recognize these types defined in ExtendedDataTypes package and map them to appropriate platform types. If the answer is yes, then in fact we will still have the same large set of primitive types as before. If the answer is no - the types are optional, then it will make those types in ExtendedDataTypes package unusable because of interoperability reasons... Martin From: "Dirckze, Ravi" To: Martin Matula , Stephen Crawley , mof-rtf@omg.org Subject: RE: Chapter 3 data type changes Date: Sat, 23 Jun 2001 13:14:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 2\He9`:Pd9!%Zd9c>#!! > .... If > the answer is no - the types are optional, then it will make > those types in > ExtendedDataTypes package unusable because of > interoperability reasons... The answer is no. However, if the optional extendedDataTypes package list the mappings to the popular languages (and all limitations, if any), then the choice is up to the user. The motivation for this compromise is the following: The data types issue can be separated into two issues: 1 - an attempt to represent middleware independent data types; and 2 - interoperability. With respect to 1, at the metamodel level, we need to represent logical (i.e., middleware independent) primitive types so that a metamodeler can describe the type of an attribute, parameter, etc.. This is because MOF is a language for metamodling. This requires that the type be logical as: 1 - the choice of physical type depends on the chosen middleware, business requirements, etc. - it is an implementation choice; 2 - logical types are language/technology independent allowing MOF to be mapped to multiple languages and middleware. Now lets look at the second requirement. In addition to being a metamodeling language, MOF also defines mappings to different middleware. Here it needs to address interoperability between these different middleware. You *CANNOT* achieve 100% interoperability without having a single primitive types system across all middleware. Since any two middleware do not share the same primitive type system, the only way to achieve this is for MOF to define it's own type system. These are conflicting requirements. If MOF defines it's own concrete type system, it is bound by that system. Unless all the middleware support MOF's type system, you do not have 100% match with the native middleware types, raising mapping issues. On the other hand, if the MOF type system is not concrete, you have interoperability issues. Therefore, I don't believe that we will ever have a perfect solution for this issue, in which case, we should be looking for a *GOOD* compromise. IMO, a good compromise is: 1. MOF defines only a minimal subset of logical types (each language mapping provide a default mapping for these types). By defining only logical types, MOF is truly middleware/technology independent. By keeping it to a minimal set, we minimize interoperability issues between different middleware. 2. We define an optional or "recommended" concrete type system that lists *all* the mapping/interoperability issues for each and every type, and let the user decide what types to use and what types not to use. I, for one, do not think (2) is necessary. This is because I am willing to allow the MOF user to ultimately decide on the interoperability issue. I understand that not everyone thinks this way. Adios, Ravi Dirckze, PhD. ravi.dirckze@unisys.com 949/380-4907 > -----Original Message----- > From: Martin Matula [mailto:martin.matula@czech.sun.com] > Sent: Saturday, June 23, 2001 4:31 AM > To: Dirckze, Ravi; Stephen Crawley; mof-rtf@omg.org > Subject: Re: Chapter 3 data type changes > > > Hi Ravi, > > > 3) define an *optional* Package called ExtendedDataTypes that that > contains > > instances for Integer32, Float32, UTF16String, and whatever else is > thought > > of as common data types used for metamodeling. > > When I am reading these lines it is not clear to me, whether > you agree, that > mappings should recognize these types defined in > ExtendedDataTypes package > and map them to appropriate platform types. If the answer is > yes, then in > fact we will still have the same large set of primitive types > as before. If > the answer is no - the types are optional, then it will make > those types in > ExtendedDataTypes package unusable because of > interoperability reasons... > Martin > > X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Dirckze, Ravi" cc: Stephen Crawley , mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Chapter 3 data type changes In-Reply-To: Message from "Dirckze, Ravi" of "Fri, 22 Jun 2001 21:01:16 EST." Mime-Version: 1.0 Date: Mon, 25 Jun 2001 11:09:55 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: =))e9nL!e9#f1e9hVf!! > I for one, tend to agree with Martin's comment (from his subsequent e-mail) > about defining a minimal subset and adding more types when there is > sufficient demand for them. Fair enough. But I must repeat my counter arguments. In practice, there is unlikely to be agreement to add new data types: 1) Vendors that think that MOF should only support meta-modelling (and not broader use for information modelling) are likely to resist on principle. 2) Vendors that have implemented non-standard data type extensions are might resist for a variety of not particularly worthy reasons. 3) The number of standards / standards committees involved may make it too hard. IMO, if we don't define (at least) a token set of representation oriented data types from day one, they won't get added in the forseeable future. Trust me ... I've seen this happen before. > I also think that Steve's proposal is an interesting compromise. I would > like to propose a slight modification to Steve's proposal here: > > 1. Define a PrimitiveTypes package as part of the core specification that > contains 4 standard PrimitiveType instances as before, with names "Boolean", > "String", "Integer" and "Float" (you can even call it "UnivarsalInteger", > etc.). Define a *default* mapping (or recommended mapping) for these types > as follows: > > > Integer - with constraint limiting to -2**31 to 2**31 - 1 > > Float - IEEE single precision floating point > > String - UTF16 string (no NUL) IMO, a "default" mapping of supposedly abstract, unbounded datatypes (e.g. the infinite set of integers) to a significantly bounded type (e.g. 32 bit signed) is a REALLY BAD IDEA. In effect, this is telling a meta-modeller that he can only rely on being able to use "Integer" to represent a 32 bit value: * Meta-modellers who are serious about interoperability will be forced to do hacky things with tuples of integers to represent larger values. This will lead to ugly APIs, user complaints, etc. * Meta-modellers who are not concerned (or don't understand) may rely on the behaviour of some vendors product in which a non-default mapping is used. This will lead to loss of information at vendor boundaries, user complaints, etc. Either way, the someone loses! We SHOULD NOT perpetuate the mistake of the C and C++ languages. We must not allow standardised data types to mean different things in different contexts. If the MOF 1.4 RTF wants to only support 32 bit integers, etc in MOF, we should be up front and define PrimitiveType("Integer") to be precisely 32 bits. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: RE: Chapter 3 data type changes -- CorbaIdlTypes? Mime-Version: 1.0 Date: Tue, 26 Jun 2001 12:15:41 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: l_p!!>H-!!PT!"!7dI!! Folks, This is the result of a phone call with Ravi and Don a few minutes ago. [Sorry Martin ... time pressure ... ] Assuming that we define a collection of interoperable builtin data types for MOF 1.4, should we also provide a collection of additional types that are specific to the IDL mapping? 1) Define a new package called (say) CorbaIdlTypes containing definitions of SOME of the CORBA builtin data types. The text would CLEARLY state that CorbaIdlTypes is intended SOLELY to provide a migration path from MOF 1.3 and earlier. Use in new meta-models is strongly discouraged. 2) The CorbaIdlTypes data types would be: CorbaCharacter ... 8 bit CorbaWideCharacter ... 16 bit CorbaString ... 8 bit, no NUL CorbaOctet ... unsigned 8 bit number CorbaShort ... 16 bit CorbaUnsignedShort ... 16 bit CorbaUnsignedLong ... 32 bit CorbaUnsignedLongLong ... 64 bit CorbaLongDouble ... IEEE double precision extended (96 bit) NOTE: there is no support for TypeCode or Any, as this would get in the way of removing the need to support these types in XMI 1.2. [There is a question that maybe we need a technology neutral equivalent for "any", but this requires a lot of thought and debate, and I don't think we can afford the time right now.] 3) An implementation of the IDL mapping would be required to support these data types. Other mappings would most likely NOT support them. Thus, these are NOT suitable for technology neutral meta- modelling. 4) The representation of the types would depend on the outcome of the decision on representing interoperable types. [It looks likely that they would be PrimitiveType instances ... ] What do people feel about this? -- Steve From: "Martin Matula" To: "Stephen Crawley" Cc: References: <200106260136.f5Q1aq601298@piglet.dstc.edu.au> Subject: Re: URGENT - data type straw poll Date: Tue, 26 Jun 2001 11:01:51 +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: m[@!! To: "Baisley, Donald E" Cc: ; Sent: Tuesday, June 26, 2001 3:37 AM Subject: Re: URGENT - data type straw poll > > Don / Ravi, > > I think adding a couple of extra primitive data types to option 1) >is a > definite improvement. > > My (ammended) preference is: > > First - 3 > Second - 2 > Third - 1a > Fourth - 1 > > Note that if we go for 1 or 1a, the second question on AliasType > constraints is irrelevant. > > -- Steve > > > Ravi and I recommend option 1a: > > > > The PrimitiveTypes package contains the following types. > > > > Boolean (true and false) > > Integer (32 bit) > > Long (64 bit) > > Float (IEEE) > > Double (IEEE) > > String (Unicode) > > > > All of these types map easily to Java, CORBA and XML. > > > > Regards, > > Don and Ravi > > > > -----Original Message----- > > From: Stephen Crawley [mailto:crawley@dstc.edu.au] > > Sent: Monday, June 25, 2001 4:57 PM > > To: Dirckze, Ravi; mof-rtf@omg.org; crawley@dstc.edu.au > > Subject: URGENT - data type straw poll > > > > > > > > Folks, > > > > We urgently need to come to a conclusion on the primitive data >types > > stuff. IMO, the best way to move things forwards is to take a >straw > > poll. > > > > There are basically 4 alternatives on the table for the semantics, > > representation and standardisation of simple data types: > > > > 1) The original JMI version in which Integer / Float / String > > are restricted to 32 bit integers / floats and UTF16 strings > > (without NUL). > > > > 2) The one in the document circulated last week in which > > Integer / Float / String are unbounded, and PrimitiveTypes > > contains a few aliases for more restricted, but widely > > implementable subtypes. > > > > 3) The compromise I emailed after the last RTF meeting in which > > Integer / Float / String are renamed UniversalInteger / > > UniversalFloat / UniversalString, and PrimitiveType also > > contains bounded versions of Integer / Float / String. > > > > The other representational types are relegated to an > > OPTIONAL ExtendedDataTypes package. > > > > 4) Ravi's modification of 3) in which the base primitive types > > have "default" mappings to bounded types. > > > > QUESTION 1: rank the alternatives above in your order of >preference. If > > there is any alternative that would be totally unacceptable to >you, > > please indicate this. > > > > Orthogonal to this, Martin wants the mapping of >AliasType(PrimitiveType) > > elements to concrete data types to be based on the expressions of >the > > Constraints on the AliasType instances. Provided we place some > > restrictions on how the Constraints are expresses (e.g some small >subset > > of OCL) this would be technically feasible, and (IMO) the >implementation > > complexity wouldn't be that great. However, if I recall >correctly, Don > > (?) was / is (?) against any need to understand constraint >expressions. > > > > QUESTION 2: do you want to continue pursuing the option? > > > > -- Steve > From: "Martin Matula" To: "Stephen Crawley" Cc: References: <200106260215.f5Q2FQ607206@piglet.dstc.edu.au> Subject: Re: Chapter 3 data type changes -- CorbaIdlTypes? Date: Tue, 26 Jun 2001 11:13:36 +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: P]pd9E%Ud96WRd9keh!! I don't think it is a good idea. I don't see why this would be useful. Does IDL want to have its own non-interoperable technology dependent MOF? However, if that will make everybody happy, then ok..... If this will be done, I think these types should be modeled as instances of PrimitiveType. Martin ----- Original Message ----- From: "Stephen Crawley" To: Sent: Tuesday, June 26, 2001 4:15 AM Subject: RE: Chapter 3 data type changes -- CorbaIdlTypes? > > Folks, > > This is the result of a phone call with Ravi and Don a few minutes >ago. > [Sorry Martin ... time pressure ... ] > > Assuming that we define a collection of interoperable builtin data >types > for MOF 1.4, should we also provide a collection of additional types >that > are specific to the IDL mapping? > > 1) Define a new package called (say) CorbaIdlTypes containing definitions > of SOME of the CORBA builtin data types. The text would >CLEARLY state > that CorbaIdlTypes is intended SOLELY to provide a migration >path from > MOF 1.3 and earlier. Use in new meta-models is strongly discouraged. > > 2) The CorbaIdlTypes data types would be: > > CorbaCharacter ... 8 bit > CorbaWideCharacter ... 16 bit > CorbaString ... 8 bit, no NUL > CorbaOctet ... unsigned 8 bit number > CorbaShort ... 16 bit > CorbaUnsignedShort ... 16 bit > CorbaUnsignedLong ... 32 bit > CorbaUnsignedLongLong ... 64 bit > CorbaLongDouble ... IEEE double precision extended >(96 bit) > > NOTE: there is no support for TypeCode or Any, as this would >get > in the way of removing the need to support these types in > XMI 1.2. [There is a question that maybe we need a >technology > neutral equivalent for "any", but this requires a lot of >thought > and debate, and I don't think we can afford the time right >now.] > > 3) An implementation of the IDL mapping would be required to >support > these data types. Other mappings would most likely NOT >support > them. Thus, these are NOT suitable for technology neutral >meta- > modelling. > > 4) The representation of the types would depend on the outcome >of > the decision on representing interoperable types. [It looks > likely that they would be PrimitiveType instances ... ] > > What do people feel about this? > > -- Steve > > From: "Martin Matula" To: "Peter Denno" , "Stephen Crawley" Cc: References: <200106221454.f5MEsI606182@piglet.dstc.edu.au> <3B338FE8.20DBDF39@nist.gov> Subject: Re: Chapter 3 data type changes Date: Tue, 26 Jun 2001 11:41:36 +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: b1F!!p$Pe9im$"!ek,e9 Hi Peter, your voting has reminded me some of your concerns. I have some more comments on that. > I, for one, do not want to have to negotiate with the MOF RTF just to add a > primitive datatype. OK. Do you want to negotiate with the MOF RTF just to add a new alias type? Because that's what you will need to do, if Steve's proposal will be adopted and you will need to define your own alias of Integer type with a new range (let's say you will need to model 128-bit integer). Steve's aliases are nothing more than my primitive types. I don't like these aliases, because they look like they are something more, but they ARE NOT - they need to be recognized by implementation! That's why you would need to negotiate with MOF RTF to put them into the package of standard MOF types to be interoperable. > > I generally support the changes to chapters 3 and 4 that Steve >proposes. The > approach is an orderly means to extend the primitive datatypes. :) What if we will go with 2 or 3 and I will need to define my own 128-bit integer? 1) I will create AliasType pointing to integer. 2) Define range constraint on it. 3) Force my MOF repository vendors to change their implementations to support this particular alias type. That is how Steve's proposal works. What if we will go with 1 or 1a and I will need to define my own 128-bit integer? 1) I will create new instance of PrimitiveType called Int128 2) Force my MOF repository vendors to change their implementations to support this particular primitive type. So what's the difference? Where is the ability to add new type without having to negotiate with MOF RTF to make it standard? Note, that with all proposals (not just with 1 or 1a) it is problematic to define types with bigger ranges. In case of restricting ranges of primitive types it is possible to do it without any problems in 1 or 1a. That's because in 1 or 1a it is also possible to create AliasType to Integer and put constraint on it which says that attributes of this type can have only values between -20 and 20. The Integer will still be mapped to the same technology type, however the range will be checked each type you will try to set value of attribute of this type. But I don't see how this is possible with proposals 2 or 3. Will I have to create alias type for some standardized recognized existing alias type? (e.g. Integer8) So it will look like MyInteger (-20 to 20) aliases Integer8 (-128 to 127) aliases UniversalInteger. Many people will want to do this: MyInteger (-20 to 20) aliases UniversalInteger, but this WILL NOT BE POSSIBLE with Steve's proposal without making the new alias standard!!! Because implementations will not recognize, which technology type they should map this new integer to - they would map it to string :( Martin Date: Tue, 26 Jun 2001 12:32:39 -0400 From: Peter Denno X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Matula CC: Stephen Crawley , mof-rtf@omg.org Subject: Re: Chapter 3 data type changes References: <200106221454.f5MEsI606182@piglet.dstc.edu.au> <3B338FE8.20DBDF39@nist.gov> <039e01c0fe24$3b0ab890$844b9c81@matula> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2Q~e9$P,!!@-~!!~-Ie9 Hi Martin, 1) Agreed, I would have to go through the MOF RTF to get agreement on a new primitive type for perfect interoperability, but not for a usage where I have some control over the clients of the types I use. I think Ravi's note described this compromise quite well. 2) How would I get anyone to agree to unbounded types when the MOF doesn't even have such a notion? It is easy to define an implementation type in terms of constraints on a conceptual, unbounded type. And the constraint need not be in OCL, IMO. It is enough to say that it is (e.g.) the IEEE float type. It is probably impossible to define an unbounded type in terms of an implementation type. Unbounded types avoid the problem of defining types with bigger ranges. With the unbounded types there are no bigger ranges. The bounded types are subtypes of the unbounded types. There is not getting around this. 3) The types I want *are* the unbounded types. 4) IMHO The MOF is currently the conceptual meta-model of very little. It is a structural meta-model (a place to store things, to obtain reflective information) and some mapping techniques. Because the MOF currently isn't a conceptual meta-model, it doesn't provide a language for meta-modeling flexible enough to accommodate much modeling technology other than the current UML. What about the notion of a "the UML family of languages"? Is it (and MDA) for real, or just lip service? Some of us (I am here representing the desires of ISO TC184/SC4, ISO 10303 Express) are not as interested in the MOF for middleware. We are interested in it as a meta-model for modeling technology. And it isn't just ISO Express where I see a need, but Object Role Modeling (ORM) and various E-R and process languages could also benefit from such a MOF. For such applications, the unbounded types are a step in the right direction. Martin Matula wrote: > Hi Peter, > your voting has reminded me some of your concerns. I have some more > comments > on that. > > > I, for one, do not want to have to negotiate with the MOF RTF just > to add > a > > primitive datatype. > > OK. Do you want to negotiate with the MOF RTF just to add a new > alias type? > Because that's what you will need to do, if Steve's proposal will be > adopted > and you will need to define your own alias of Integer type with a > new range > (let's say you will need to model 128-bit integer). Steve's aliases > are > nothing more than my primitive types. I don't like these aliases, > because > they look like they are something more, but they ARE NOT - they need > to be > recognized by implementation! That's why you would need to negotiate > with > MOF RTF to put them into the package of standard MOF types to be > interoperable. > > > > > I generally support the changes to chapters 3 and 4 that Steve > proposes. > The > > approach is an orderly means to extend the primitive datatypes. > > :) What if we will go with 2 or 3 and I will need to define my own > 128-bit > integer? > 1) I will create AliasType pointing to integer. > 2) Define range constraint on it. > 3) Force my MOF repository vendors to change their implementations > to > support this particular alias type. > That is how Steve's proposal works. > > What if we will go with 1 or 1a and I will need to define my own > 128-bit > integer? > 1) I will create new instance of PrimitiveType called Int128 > 2) Force my MOF repository vendors to change their implementations > to > support this particular primitive type. > > So what's the difference? Where is the ability to add new type > without > having to negotiate with MOF RTF to make it standard? > > Note, that with all proposals (not just with 1 or 1a) it is > problematic to > define types with bigger ranges. In case of restricting ranges of > primitive > types it is possible to do it without any problems in 1 or > 1a. That's > because in 1 or 1a it is also possible to create AliasType to > Integer and > put constraint on it which says that attributes of this type can > have only > values between -20 and 20. The Integer will still be mapped to the > same > technology type, however the range will be checked each type you > will try to > set value of attribute of this type. But I don't see how this is > possible > with proposals 2 or 3. Will I have to create alias type for some > standardized recognized existing alias type? (e.g. Integer8) > So it will look like MyInteger (-20 to 20) aliases Integer8 (-128 to > 127) > aliases UniversalInteger. Many people will want to do this: > MyInteger (-20 > to 20) aliases UniversalInteger, but this WILL NOT BE POSSIBLE with > Steve's > proposal without making the new alias standard!!! Because > implementations > will not recognize, which technology type they should map this new > integer > to - they would map it to string :( > Martin -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8260 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8260 FAX: +1 301-975-4694 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Peter Denno , Martin Matula , "Baisley, Donald E" , "Dirckze, Ravi" Cc: Stephen Crawley , mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Chapter 3 data type changes In-Reply-To: Message from Peter Denno of "Tue, 26 Jun 2001 12:32:39 -0400." <3B38B927.49B067C2@nist.gov> Mime-Version: 1.0 Date: Wed, 27 Jun 2001 10:03: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: "U`!!\Z+!!;]He97-6!! Folks, Thanks to those of you who took the time to respond to my straw poll. I've concluded that it would be unwise to try to continue down the "infinite types" path for the MOF 1.4 RTF. My feeling is that everyone can accept primitive types with fixed limitations, even if it is not their preferred option. My feeling is that we can NOT get everyone to accept the infinite types approach ... at least in the time we have available for debating this. On this basis, I've completed the text that contains the substance of the DataType changes (Chapters 3,4,5), and put them onto DSTC's MOF RTF web page ready for your review: http://www.dstc.edu.au/Research/Projects/MOF/rtf1.4 Please read the three Chapter excerpts and be ready to raise/discuss any significant problems at this week's RTF teleconference. Please mail any minor issues, typos, etc, to the MOF RTF mailing list. [There are some other "editorial-ish" changes to be made. For example, changes to the non-normative overview in Chapter 2, changes to IDL, XMI, changes to names of types used by some Chapter 3 model elements. I'll do those against a full MOF 1.4 draft rather than the cut-down chapters I've been circulating. I'll probably start on that work next week.] -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Errata to Issue 2198 proposed resolution Mime-Version: 1.0 Date: Fri, 29 Jun 2001 09:09:00 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: !:(e97]?!!2:F!!p]`d9 These errata are against the "version 2" documents on DSTC's website: 1) In 3.3.11 (AliasType), delete the second paragraph. (Starts "It is anticipated ..."). This text is left over from version 1 of this resolution and is now meaningless. [Noted by Martin in an email to me ... ] 2) In 3.3.27 (Constant), change the type of the 'value' Attribute from 'LiteralType' to 'String'. In the IDL below, change 'LiteralType' to 'wstring', in 3 places. Some text needs to be added to explain HOW the constant values should be encoded as strings. I'll raise a separate issue for this. X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Another issue 2198 related problem - internalize and externalize Mime-Version: 1.0 Date: Tue, 03 Jul 2001 17:17:51 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: N0+e9NUod9dbAe9ejIe9 Folks, I've just run into a couple more problematical Operations in the MOF Model. The Package class has two operations "internalize" and "externalize" that are supposed to be hooks for importing and exporting metadata. They are defined in MOF 1.3 with Parameters whose type is a CORBA Any and that represents some kind of input / output stream. This won't work in MOF 1.4 because "Any" is not a supported data type. We've got two choices I think: 1) We could drop these operations. They are currently underspecified and (I think) nobody currently implements them. 2) We could make them Reflective operations; e.g. on RefPackage. There is an outstanding issue that calls for operations that support XMI import/export independent of the meta-model. We could make this a fix for this issue. My preference is 1) because the RTF deadline is getting ever closer ... Comments please. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: 2189 - proposed corrigenda Mime-Version: 1.0 Date: Tue, 03 Jul 2001 16:58:52 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: UXL!!^5-!!"S#"!,p+!! These proposed corrigenda to 2198 are "significant" (non-editorial) and will need to be voted on at some point. Comments please ... 1) In order to clarify the intent on how standard PrimitiveType instances are recognized as such, insert into 3.9 (PrimitiveTypes) the following sentences. "Technology mappings shall recognize standard PrimitiveType instances based on their qualified names. Multiple PrimitiveType instances with the required qualified name are deemed to mean the same thing." [This should tie a loose end so that we can back out of the UUID tar pit.] 2) To make the MOF -> IDL mapping work, we need to make sure that StructureTypes contain AT LEAST ONE StructureField. We could make this an "IDL mapping precondition", but I think it is more sensible to make this a Constraint on the MOF Model. I therefore propose the following Constraint be added to StructureType: [C-XX] MustHaveFields -- "A StructureType must contain at least one StructureField.", evaluationPolicy: deferred, OCL: TBD. [I'll probably find more corrigenda as I do the editing. Stay tuned.] -- Steve From: "Martin Matula" To: , "Stephen Crawley" References: <200107030717.f637Hn412235@piglet.dstc.edu.au> Subject: Re: Another issue 2198 related problem - internalize and externalize Date: Tue, 3 Jul 2001 09:53: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: ob;!!"'md9NBpd9@cmd9 I vote for 1). However, in future it would be nice to have a standard interface for XMI Reader/Writer in IDL mapping. We did this in JMI. Martin ----- Original Message ----- From: "Stephen Crawley" To: Sent: Tuesday, July 03, 2001 9:17 AM Subject: Another issue 2198 related problem - internalize and externalize > > Folks, > > I've just run into a couple more problematical Operations in the MOF Model. > The Package class has two operations "internalize" and "externalize" >that > are supposed to be hooks for importing and exporting metadata. They >are > defined in MOF 1.3 with Parameters whose type is a CORBA Any and >that > represents some kind of input / output stream. This won't work in >MOF > 1.4 because "Any" is not a supported data type. > > We've got two choices I think: > > 1) We could drop these operations. They are currently >underspecified > and (I think) nobody currently implements them. > > 2) We could make them Reflective operations; e.g. on RefPackage. >There > is an outstanding issue that calls for operations that support >XMI > import/export independent of the meta-model. We could make >this a > fix for this issue. > > My preference is 1) because the RTF deadline is getting ever closer >... > > Comments please. > > -- Steve > From: "Baisley, Donald E" To: mof-rtf@omg.org Subject: RE: Another issue 2198 related problem - internalize and external ize Date: Tue, 3 Jul 2001 15:30:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3"H!!$Ukd9-RX!!'M\!! I prefer choice number 1. Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Tuesday, July 03, 2001 12:18 AM To: mof-rtf@omg.org Subject: Another issue 2198 related problem - internalize and externalize Folks, I've just run into a couple more problematical Operations in the MOF Model. The Package class has two operations "internalize" and "externalize" that are supposed to be hooks for importing and exporting metadata. They are defined in MOF 1.3 with Parameters whose type is a CORBA Any and that represents some kind of input / output stream. This won't work in MOF 1.4 because "Any" is not a supported data type. We've got two choices I think: 1) We could drop these operations. They are currently underspecified and (I think) nobody currently implements them. 2) We could make them Reflective operations; e.g. on RefPackage. There is an outstanding issue that calls for operations that support XMI import/export independent of the meta-model. We could make this a fix for this issue. My preference is 1) because the RTF deadline is getting ever closer ... Comments please. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: More 2198 corrigenda Mime-Version: 1.0 Date: Thu, 05 Jul 2001 15:13:54 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: \cB!!!,Sd94^ cc: mof-rtf@omg.org, crawley@dstc.edu.au Subject: Even more 2198 corrigenda In-Reply-To: Message from Stephen Crawley of "Thu, 05 Jul 2001 15:13:54 +1000." <200107050513.f655Dp421824@piglet.dstc.edu.au> Mime-Version: 1.0 Date: Thu, 05 Jul 2001 16:37:27 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: IAp!!(JCe9!$[!!;'4!! > Some more 2198 corrections ... hopefully the last batch. Nope. One more. 6) Add text to 3.10.* and 5.3.1 to say how Constant values for the PrimitiveTypes and CorbaIdlTypes are encoded; i.e. the "value" field of Model::Constant ... which used to be Any and now is String (16 bits). * Boolean is "TRUE" or "FALSE" * Integer types are CORBA IDL integer literal syntax with optional * leading '-' * Floating point types are CORBA IDL floating point literal syntax * with optional leading '-'. * String types are unencoded. * Character types uare unencoded except that an NUL is represented * by an empty string. (NUL not being an allowed in an * PrimitiveType::String)