Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSR 40 Issues
Status Issue ID Description Date Reported by Notes Resolution
mof I0013 The 'CollectionType' Class is underspecified. ? If it is to subsume arrays and collections, then you need more attributes. At least you need to be able to distinguish between a fixed sized array and a variable sized (maybe bounded) sequence. 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0014 The 'StructType' Class is underspecified. ? If it can have "members", you need to specify the restrictions on them. 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0015 The 'PrimitiveType' Class should not support 'java.lang.Object'. This is the same mistake we made ... and later regretted ... when we allowed CORBA Object types (and Any and TypeCode) to be part of the OMG MOF's data type system. Leave it out for now, and put it back in when MOF 2.0 can separate technology-neutral and technology-specific types. - In particular, the use of 'Object' in 'Tag' etc is going to be problematical for interoperability. 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
resolved I0016 I do not think it is appropriate for Chapter 3 to be so skinny ... even in a draft for review. ? All the important stuff is hidden in the XMI addendum. ? It is unreasonable to expect people to read that!! 3/12/01 S. Crawley   (7/13/2001) Chapter 3 is to be expanded sufficiently for JMI to be a self contained document, i.e., the reader should not be *required* to read the MOF specification to make sense of JMI. In addition, since JMI is to be based on MOF 1.4 which includes a technology independent type system, Chapter 3 needs to provide an ? introduction to the MOF data types instead of the JMI type system.
mof I0017 It is not clear how the Java Language APIs for the JMI MOF were produced. ? In particular, I don't see how you told the Model -> Java mapping to suppress the 'typecode' attribute of DataType from the javax.jmi.model.DataType interface ... and friends. ? [And frankly, I don't think they should be completely suppressed.] 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0018 The JMI spec says that the typeCode field on DataTypes is ignored. If you stick with this, JMI won't be able to understand DataTypes in XMI from an OMG MOF. ? The same works in reverse. ? In JMI, DataType effectively becomes 'abstract', because all instances will be instances of one of the new Classes; AliasType, PrimitiveType, etc. ? But unless these instances have viable TypeCodes, an OMG MOF won't be able to understand XMI from a JMI MOF. I don't know the best solution to this. ? Maybe, the 'typecode' attribute should be informally defined as derived from information in sub-Classes of DataType. The attempt to remove the CORBA dependencies of DataType is problematical. ? While this work needs to be done, in the short term you are creating interoperability problems with the OMG MOF Model, ? and the rest of the OMG metadata framework. The work to remove CORBA data type dependencies really should be done in response to the OMG MOF 2.0 RFP, with JMI tracking the OMG MOF sepc. 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0019 JSR040 has no business using prefixes that start with "org.omg". 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0020 Should the metamodel of JMOF be MOF1.3?? The base meta-model is clearly not MOF OMG Model 1.3, since the datatypes are represented in a JMI'ish sort of way. ? Yet there is no such thing as version 1.4 of "Model" ... so the meta-model version element is bogus. ? Even weirder, the XMI contains a bunch of XMI.Any elements, and even some XMI.CorbaTypeCode elements ... neither of which should be necessary in a JMI meta-model of JMI. Why is it necessary to use CORBA specific types at all? Isn't the JMI Model capable of self description? To be useful, the XMI needs to use a meta-model that is pure JMI Model or pure MOF Model ... not some unspecified hybrid of the two. I think the spec of the JMI Model in terms of the MOF Model is most important right now. ? The OMG MOF Model has a number of existing implementations, and this should allow you to bootstrap the JMI Model and initial tools. 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0021 The Package "Model" name should be different to that used for the OMG MOF's meta-meta-model. ? Or at the very least the IDL prefix (defined in the XMI) should be different! 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0022 It would be better if the JMI "Model" Package was defined as a sub-Package of the OMG MOF "Model" Package. ? As far as I can see from the changes that have been made, this is should be workable [Removing / relaxing Constraints is dubious, but given the lack of definition of Constraints in the MOF spec, it should be ok in practice.]... If the JMI Model Package is a subtype of the OMG MOF Package, then a client of the OMG MOF IDL will be able to talk to a JMI repository with IDL APIs. If not, then this is not possible. ? Ditto for XMI interchange. 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0023 The JMI Model should be defined strictly using OMG MOF meta-modeling constructs. ? For example, appears (from skimming the XMI) that you use Model.EnumerationType to define some of the JMI Model data types. - ? If you stick strictly with the MOF Model as the meta-model for the JMI Model, the MOF IDL mapping will work for JMI. If you don't, it won't. This would be a BAD THING! 3/12/01 S. Crawley   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0024 Should we remove verify operation from ModelElement? 4/23/01 C. Plotnikov   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0025 I suggest to remove typecode completly from that class. If corba generator will need to access typecode, it could get it from tagged value. 4/23/01 C. Plotnikov   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
mof I0026 I suggest collection type to have multiplicity instead of upper. It will allow to specify ordering, uniques and lower bound too. This will better integrate collections with the rest of the MOF. 4/23/01 C. Plotnikov   This is an issue with the MOF, and as such, has been forwarded to the MOF RTF (Revision Task Force).
resolved I0027 Page 35: I suggest to drop the following statement in the list of set<attributeName> operation restrictions: 'If the attribute's multiplicity has a "lower" value greater than zero, there must be at least that many elements in the collection.' Less elements should also be allowed (e.g. during the model creation) 4/23/01 C. Plotnikov   (6/22/2001) Modify the spec as proposed.
resolved I0028 Synchronize usage of null values in JMI with MOF (does null = no value?, can it be value of a collection element?, etc.) 4/23/01 C. Plotnikov Restrictions for set<attrName> operation on page 35 say that it is possible to pass null in collection. Is this correct? // Original text of this issue was "Should we disallow passing null value as element of a collection?". On the confcall 6/22/2001 we have decided to reformulate this issue as it is more complicated. (7/20/2001) State clearly that null object references will not be supported in JMI - java null will represent no value in JMI. It will be disallowed to use null elements in collections representing value of multivalued parameters and attributes.
resolved I0029 exists(), add(...) and remove(...) methods in Association template do not carry information about with argument is first and which is second. This will require a knowing metamodel. I suggest to introduct two variants of methods for each role. This will simplify usage of association interface and will make add() and remove() methods similar to other methods in the interface. 4/23/01 C. Plotnikov   (6/22/2001) Leave it as is.
resolved I0030 Accessor for getting association end is named with just <AssociationEndXName>(). This violates common java convention that any method should started from verb or verb phrase. 4/23/01 C. Plotnikov   (6/22/2001) Change method name to get<AssociationEndXName>().
resolved I0031 Should we represent unique multivalued attributes/references as java.util.Set? 4/23/01 C. Plotnikov   (6/22/2001) Leave it as is (don't use java.util.Set).
resolved I0032 If proposal with multiplicity will be adopted, then collection type could be mapped to other types then list depending on ordering, uniques, and multiplicity specifications. 4/23/01 C. Plotnikov   (7/13/2001) This mapping was agreed to with the fooling comments/recommendations: The interface makes a distinction between orderedness but not of uniqueness because orderedness is a characteristic of the multi-valued attribute/reference, while uniqueness is a constraint on the attribute/reference. This leaves the spec unclear has to what is to be expected when the uniqueness constraint is violated. If a JMI implementation choose to implement the java.util.Set interface for unique multivalued attributes, the Set interface states that the add(...) operation returns false when a duplicate is added, while JMI states that the DuplicateException is to be thrown. To clarify the behavior, the spec will state that the DuplicateException is to be thrown when a duplicate value is added to a (JMI) collection where the isUnique property is true.
resolved I0033 There is an complication with generations of structs. Interfaces to creation structs are complicated and do not support serialization very well because an implementation class should be on other side. I suggest to make struct classes rather then intefaces. This will allow more clear seriliazation interfaces. 4/23/01 C. Plotnikov   In order to support different implementation requirements, structs and enums will continue to be mapped to interfaces.
resolved I0034 We should consider replacing all RefObject arguments representing meta elements in reflective calls by String arguments representing names of these meta elements. 4/23/01 C. Plotnikov   (6/22/2001) Leave it as is (don't use strings instead of RefObject)
resolved I0035 Change refTypeName() operation in RefEnum and RefStruct to return "." or "/" -separated string instead of List. 4/23/01 C. Plotnikov   (7/27/2001) Return List (keep as is) - this is mainly because MOF does not put any restrictions on characters used in strings.
resolved I0036 It needs to be specified, how the JMI service should handle collections. Will modifications of collections returned from JMI operations modify the JMI object? Will the returned collections be readonly? Will they change when JMI object changes? Will collections passed to JMI calls cause change of object when they are changed? etc. 4/23/01 C. Plotnikov   (7/13/2001) The collection semantics are as follows: 1 - live collection semantics, i.e., the user can update the source using the collection API; 2 - live iterator semantics, i.e., the user can update the source using the iterator; and 3 - each operation on a JMI collection (collection returned by a JMI service) is an atomic operation, e.g., ? CollectionFromJmiService.toArray(...) is an atomic operation.