| 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. |
