1) The pseudo-code specification in 7.2.2 contains embedded EBNF, that
is quite distinct from the earlier EBNF. It uses different lexical
conventions (e.g. 'S' and 'Q' meta-syntactic elements), the productions
have different numbering, and the non-terminal symbols are different.
The two sets of EBNF should be identical.

2) All "," comma separated lists defined in the pseudo-code should be
replaced with "|" separated lists.

3) Multiplicities for XML elements affect the DTD according to the
pseudo-code, but not according to the EBNF. The text of 6.6.5 (last
para) implies that the EBNF is correct. Fix the pseudo-code.

4) In the pseudo-code, it is unclear whether the phrase "parent Package"
means the Package containing the given Package, or a Package this
Package inherits from, or both. For example, in the description and
pseudo-code for GetClassLevelAttributes.

Removal of obsolete OCL and pseudo-code

Would allow more flexible customization of XMI serialization by supporting both of the most common serialization preferences.

Close, no change

Question if both XML element and XML attribute declarations are meant to be defined. No change. The declarations present in the text are intentional.

No change. The declarations present in the text are intentional

"Section 6.6.1, the first sentence of the first full paragraph on p-67 uses the term ""short name""" "Accept. Omit the reference to ""short name."" "

Accept. Replace "short name" with "name".

. Item 20/2924 of XMI 1.1 RTF was not fully completed. Apply to sections 6.5.1 and rule 7e of document production. Accept. Clarify the use of UUIDs.

see above

"The OCL and pseudo-code ""maintained for reference"" are not updated to XMI 1.1. Example, Section 9.5.4" .

Removal of obsolete OCL and pseudo-code

"The reference in the ""except"" clause of ""Association Specification"" in section 6.6.6 is not consistent with ""Containment Specification"" in section 6.6.7." Accept. The except clause will be dropped.

The except clause will be dropped.

"The reference in the ""except"" clause of ""Association Specification"" in section 6.6.6 is to text that was removed." Accept. The except clause will be dropped.

The except clause will be dropped

Nested classes currently do not follow the even/odd standard progression of element nesting. Add an intermediary element.

Close, no change

The XMI RTF meeting in Mesa had consensus that the extra declarations for element attributes for backwards compatibility with XMI 1.0 are no longer needed.

see above

Question if both MOF and UML were defining the same tag values for initialValue. No change. This is a DTD initialValue which differs from UML's initial value.

No change. This is a DTD initialValue which differs from UML's initial value

Fixed DTD declarations for CORBA need to be clarified in 6.2.2 compared to 6.5.18 and 7.5. "Accept - see AB issues sheet. Clarify to indicate only the required elements in section 7.5."

see above

"The OCL and pseudo-code ""maintained for reference"" are not updated to XMI 1.1. Example, Section 7.2.2" Accept. The OCL and pseuo-code will be removed.

Removal of obsolete OCL and pseudo-code

Multiplicity should match 6.6.2. EBNF takes precedence. Accept. The Pseudo-code will be dropped.

Removal of obsolete pseudo-code.

How does an XMI 1.1 document represent multi-valued attribute values?
For example, suppose we have an attribute "foo" with type == 'string'
and multiplicity of '0..*'. How do you represent this attributes
value when it contains multiple strings; e.g.

from

.

On OCL on pages 9-217 and 9-221 seems to say:

<pkg.cls.foo>
<XMI.seqItem> string1 </XMI.seqItem>
<XMI.seqItem> string2 </XMI.seqItem>
</pkg.cls.foo>

see above

There are inconsistencies between the EBNF and pseudo-code with respect
to handling of multiplicities in EBNF productions 6f, 9c, 9d and 12c.
Typically the EBNF us a '|' separated list and the pseudo-code uses ','
or a mixture of '|' and ','.

Removal of obsolete OCL and pseudo-code

The XMI document production rules for the encoding of CORBA "any" values
have the following problems:

1) The EBNF rules added in XMI 1.1 (page 9-205 of ad/99-10-02) say
*nothing* about how to encode an "any" value ... or a TypeCode for
that matter.

2) The encoding of TypeCode information for an Any value is different
from the encoding of a bare TypeCode value. IMO, this is an
unnecessary optimisation (saves only a few bytes over referring
to TypeCodes by some kind of idref). It has the disadvantage
of making implementation more complex.

3) The TypeId production is a bit broken:

a) A literal reading of the AnyValue and TypeId productions
says that an "any" value can be encoded with no type
information. In fact, the 'empty' third case of the
TypeId should be deleted ... or better, the TypeRef
production should be folded in.

b) The second branch of the TypeId production uses a "xmi.name"
attribute to refer to a TypeCode via its fully-qualified
DataType name. I don't know how an XMI document consumer
is going to resolve such a reference. Please explain!

Wouldn't it be better to use the TypeCode repository id?

c) In the second branch again, if a TypeCode is identified
by an "xmi.name" attribute, the "xmi.kind" attribute is
redundant.

4) The CorbaTypeName production (9.5.10.2) is incompletely
specified. It says "deduce pattern from above" ... but I can
think of more than one plausible "pattern".

Close with no action because of updates to MOF 1.4 datatypes

Consider the following CORBA union type:

union Foo switch(long)

;

The production rules in 9.5.7.4 and 9.5.9.9 do not say how a "Foo" value
should be encoded in an XML document when the discriminator is (say) zero.
(The OCL for 9.5.9.9 will give an exception in CORBA 2.3 in this case.)

Should the Foo value be encoded in XMI as:

<XMI.unionDiscrim>0</XMI.unionDiscrim>

or

<XMI.unionDiscrim>0</XMI.unionDiscrim>
<XMI.field></XMI.field>

or something else?

Close with no action because of updates to MOF 1.4 datatypes.

There is an inconsistency between the EBNF and pseudocode that
generates DTD element declarations for Classes. According to
the EBNF (production 6a) the element name is the "name of Class"
preceded by an optional namespace. According to the EBNF, the
element name is a the qualified Class name.

There are two issues:

1) If we follow the EBNF and use an unqualified name, there is
a risk of name collision when there are Classes in nested Packages.

2) If we follow the pseudo-code, we lose the namespace prefix.

see above

The XMI spec currently defines 3 rulesets for generating DTDs for
meta-models. The rulesets give different DTDs, but they are all intended
to match (i.e. be capable of validating) the document production rules
in Chapter 9.

Given that the 3 kinds of DTDs are equivalent, why do we need them all?
The point of XMI is the interchange of metadata, not the generation of
pretty DTDs. Indeed, the XMI DTD compliance section (11.2.1) makes
it clear that any DTD that expands to the same form is compliant.

I suggest we just delete the compact DTD rulesets, and leave the
implementation of "pretty" DTDs as an exercise for the implementor
to undertake ... or not. The alternative is that we must ensure that
any changes / corrections are made to the simple ruleset are made to
the other two rulesets.

Remove DTD rule sets 2 and 3 in chapter 4

The pseudo-code in DTD ruleset 1 for Attributes and References generates
DTDs in which '?', '+' or '*' may be generated depending on the
element's
multiplicity. The earlier EBNF uses '*' only.

Removal of obsolete OCL and pseudo-code

There is a discrepancy between the text describing EBNF production 9e
and the corresponding pseudo-code. According to the EBNF description,
only Classes directly contained by this Package or Classes directly
contained by this Package's direct and indirect super-Packages are
included. According to the pseudo-code (e.g. GetPackageClasses on
page 7-113), Classes from containing Packages and their super-Packages
are also included.

see above

This relates to productions in DTD ruleset 1

1) In 6f, what on earth is "an ownedElement of a Class"? This is not
a recognisable MOF meta-modelling concept.

2) In 6f, what subclasses need to be included? Those declared in
this
Package? In nested Packages? In Packages that import, cluster
or inherit this Package? More?

3) In 6e, how come you don't also include names of subclasses of the
types of the References?

Removal of obsolete OCL and pseudo-code

According to EBNF productions 11c & 1a, an AssociationEnd in an
un-referenced
Association is represented as "%XMI.element.att;%XMI.link.att".
According
to the pseudo-code, it is just "%XMI.link.att".

Removal of obsolete OCL and pseudo-code

This relates to DTD ruleset 1 production 9c. According to the EBNF, the
XMI.extension element is present in the Package contents. According to
the pseudo-code (p 7-100) it is not included.

Removal of obsolete OCL and pseudo-code

There is a discrepancy between the text describing production 9g of DTD
ruleset 1, the pseudo-code for getContainedPackages and its description.
The first two say that PkgPackages contains any nested Packages from
super-Packages, but the description for getContainedPackages does not
mention this.

Also, it is not crystal clear what "nested Packages" means in 9g (and
by extension in other places). It should mean all Packages that
are directly or indirectly contained by a Package., but this needs to
be spelled out somewhere.

see above

The EBNF (4d, 4f) and pseudo-code for Attribute contents in the simple
DTD ruleset seem to support multi-valued Attributes in different ways.
In the EBNF, "attribute contents" have an enclosing "( )*" in the two
cases that matter. By contrast, in the pseudo-code, the "( )*" 's are
sometimes present and sometimes absent.

I think the EBNF is probably correct.

There are also some minor meta-syntax errors in the pseudo-code;
e.g. missing quotes.

Removal of obsolete OCL and pseudo-code

The EBNF seems to be generating "|" separated lists for the
contents of a Class, but the pseudo-code generates "," separated lists.
This seems to occur with the attribute and reference lists as well
as the overall contents list.

In the pseudo-code, 'GetAllReferences' returns all References, but the
EBNF excludes those References whose exposedEnd is composite.

Removal of obsolete OCL and pseudo-code

In the XMI spec, on page 9-175, it says that EmbeddedObject serves as an alternative to ObjectAsElement for cases where an identifier is not required (i.e. the object participates in no links). However, the EBNF says that an ObjectAsElement is included between the tags (The OCL uses ObjectContents). Can I assume that this is a problem with the XMI spec, and that it should be ObjectContents?"

Removal of obsolete pseudo-code (section 6.4).

Since the DTD rule sets 2 and 3 have been removed, along with the
pseudo-code, a discussion of the possible uses of entity definitions in XMI
DTDs should be included in the specification to help people implement XMI
DTD generation.

see above

The "fixed elements" for XMI.CorbaTypeCode in sections 6.5.18 & 7.5 are buggy.
There is no element for the "unsigned long long" TypeCode, and the element
for the "fixed" TypeCode is not allowed in XMI.CorbaTypeCode.

In addition, we should consider extending XMI's support of TypeCodes and
Anys to cover the "value" types added in CORBA 2.3. [We don't need to
handle Attributes with "value" types at this stage because MOF doesn't
support this in meta-models.]

Editorial: The "fixed" DataType DTD elements appear BOTH in section
6.5.18 and in section 7.5. Could we replace the former with a reference
to the latter?

Close with no action because of updates to MOF 1.4 datatypes

In trying to implement the production rules for representing CORBA anys in XMI
document, I've concluded that the current definition is unnecessarily complex.
This impacts on the producer and consumers of XMI documents in (I believe)
unforseen ways.

Currently, the TypeCode information for an 'any' can be represented in a
number of ways according to 9.5.7.12 & 9.5.8.1:

1) If the type is primitive, it is represented by the 'xmi.kind'
[or 'xmi.type' according to 6.5.18] attribute of the XMI.any element.

2) Otherwise, if the type is defined in the source meta-model, it is
represented by the "xmi.name" attribute. This gives a qualified
name of a DataType in the meta-model.

3) Otherwise, the type is represented as an "href" attribute. This
presumably must link to an XMI.CorbaTypeCode element elsewhere
in the current document or in another one. [The spec doesn't say
this, but this interpretation makes sense.]

The first case works, though it does mean that simple types are represented
differently depending on their context (see 9.5.8.15). [This is not good,
but it isn't hard to handle.]

The second case is rather problematical:

• The XMI.any will also have an "xmi.kind" attribute, but this attribute
  won't be correct for a CORBA any whose type is a tk_alias.

• More importantly, generating and resolving the qualified name
  requires that the producer and consumer to have the meta-model
  at their disposal at runtime. Or at least to know the mapping
  between DataType qualified names and TypeCodes.

• Mapping from TypeCodes to qualified names is expensive because
  the standard CORBA TypeCode API does not provide a hash function.

• Finally, it is unclear what model of "equality" of TypeCodes
  should be used. This is significant because the MOF does tricky
  things with repository ids in embedded TypeCode values that
  mean that the TypeCodes in a meta-model won't be identical to
  the TypeCodes generated by an IDL compiler and used in a typical
  CORBA any value.

The third case could also be problematical if the XMI.CorbaTypeCode elements
are defined in a separate document. If the documents get separated, it
is no longer possible to correctly interpret the XMI.any values. This
particularly significant given that the contents of an XMI.any element
do not give much type information.

Finally, it is not clear what should happen if a producer encounters an IOR for
instance of a Class in an any. Probably it should treat this via case 3) but
the spec doesn't state this explicitly.

My recommendation would be to redefine the XMI.any element to contain an
XMI.CorbaTypeCode element, and redefine XMI.CorbaTypeCode so that it has
three forms; i.e.

XMI.CorbaTypeCode xmi.kind="kind" / // where tc.kind() is simple
// or unbounded string

and

XMI.CorbaTypeCode xmi.idref="some id" /

and

XMI.CorbaTypeCode xmi.id="some id" typecode state /XMI.CorbaTypeCode

This should make both Anys and TypeCodes easier / safer to handle in a wider
range of XMI implementation and runtime contexts.

The percentage expansion of the resulting XMI document should be insignificant
unless the transmitted metadata is mostly CORBA any values.

Close with no action because of updates to MOF 1.4 datatypes

Suppose that a meta-model is declared as follows:

package Foo {
class Bar

;
};

According to the XMI document production rules, the value of the "baz"
attribute should be encoded using the ObjectReference production (9.4.5.2).
This says that if the object is part of the model (e.g. an instance of
some Class defined by the meta-model), the value is encoded as:

XMI.reference xmi.idref="some_id" /

Otherwise it is encoded as

XMI.reference href="some_URL" /

Unfortunately, the latter does not work because there is no legal URL
representation for a CORBA Object reference, and you can't represent
a CORBA Object reference in some other XMI document.

I think the fix is to provide a third alternative:

XMI.reference stringified-CORBA-IOR /XMI.reference

Close with no action because of updates to MOF 1.4 datatypes

If I understand 9.5.7.10 correctly, it says that the type information for an
Any may be partly or fully represented by "xmi.kind", "xmi.id" and "href" XML
attributes of the XMI.any element. However, according to the fixed element
declarations in 6.5.18, the "XMI.any" element cannot have an "xmi.kind" or (I
think) "xmi.id" attributes. Instead, it has attributes "href", "xmi.idref",
"xmi.name" and "xmi.type".

Which attributes should be used?

Close with no action because of updates to MOF 1.4 datatypes

MOF 1.4 has had the final RTF votes. There are changes to MOF 1.4 that
result in updates to XMI 1.2. In particular, the data type simplification
in MOF 1.4 will lead to improvements for XMI 1.2.

see above

The package structure of UML 1.3 makes it difficult to deploy small parts of
the "physical" metamodel separately. For example, a MOF-based facility that
supports classes from Behavioral_Elements.Common_Behavior must support all
of Behavioral_Elements. A facility that supports Exceptions must also
support Use Cases and State Machines. This has been a problem in the
formation of the CWM metamodel which extends UML. Its interfaces and DTDs
are made to be much too large.

The result of UML currently having three metamodels (two of which are large)
rather than many smaller metamodels is that the IDL modules are very large
and so are the DTDs. Breaking the metamodels into several smaller ones will
allow smaller interface sets and DTDs that can be mixed and matched to
provide necessary functionality without a huge overhead.

No Data Available

State Machines

The metaclass StateVertext, including its subclasses PseudoState,
StubState and SyncState is not owned by a StateMachine.

The associations from StateVertext to

• container : CompositeState
• outgoing : Transition
• incoming : Tranision
  can all be empty.
  If they are all empty in a model, we do not know to which statemachine
  this StateVertex belongs. IS this the intention ?

see above

All data types used in the UML metamodels are clumped together in a
Data_Types package in the Foundation metamodel. When a new type is needed
by some other metamodel, such as for Activity Graphs, the type is added into
Foundation. This breaks the whole concept of extensibility. Data types,
like other model elements, should be defined in the specific packages where
they are needed. A new package that requires new types should include those
types itself and not impose a change on UML Foundation.

Recommendation: In the "physical" metamodel, put data types into the
packages where they are first used. For example, PseudostateKind should be
defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types.

No Data Available

The "physical" metamodel should include the OCL constraints and operations
defined in the UML Specification. This has been done in the MOF 1.3
specification. The operations provide valuable capabilities and should be
part of the standard UML facility interfaces. Making the operations part of
the "physical" metamodel allows them to be used when defining new
constraints in extension metamodels, such as in CWM.

Recommendation: Add the specification's constraints and operations to the
"physical" metamodel.

Note that adding constraints and operations will affect IDL, but it will not
affect XMI DTDs.

No Data Available

Actions in dynamically concurreny states in activity graphs need
some way to access the arguments provided by the concurrency
expression. The Reference manual suggests the "implicit" event,
but does not define what that is (p 437). Perhaps it is an the
action language issue.

No Data Available

Actions should have a isParallel attribute to specify if the iteration
is sequential or parallel.

No Data Available

Multiple languages for uninterpreted strings

The various places that uninterpreted strings are used in UML should
support multiple languages. For example, the Expression metaclass has
an metaattribute for language and another for the uninterpreted string.
This should be a set of such pairs. Then code generators can target
multiple languages from the same model.

resolved, see above

I have played a lot with different ways of showing how several collaboration specifications may appear in one class diagram.

Right now, there are collaboration specification diagrams, and there are class diagrams that feature template instantiations, but no class diagrams that feature collaboration specifications. If you use a round ellipse for hooking up a collaboration specification into a class diagram, you will see ellipses all over the place, but will not see how the collaboration specifications relate to the associations between the classes.

I can show you the variations of how to draw collaboration specifications in class diagrams. In case you wonder whether you really need this, I can offer you my whole Ph.D. thesis, which is on framework design using role modeling ) There is plenty of other work going into this direction, for example Erich Gamma’s pattern annotations in class diagrams.

No Data Available

I am not sure if this qualify as an Issue, but I what just wondering
why Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element?

No Data Available

No mapping for this in mapping section, p 3-77:

[p 3-75, Notation section for Composition] An association drawn
entirely within a border of the composite is considered to be
part of the composition.

No Data Available

ClassifierRoles should be independent of specific underlying base Classifiers. Otherwise, you can not specify OOram role models properly. You need "free" ClassifierRoles (=without base) if you want to span layers, for example.

Collaboration Templates don't do the trick; templates serve a different purpose.

Please contact me at riehle@acm.org if you want to know more. I have long worked on this topic.

No Data Available

Top state in activity graphs

The state machine meta-model currently requires a top state, whereas
activity graphs should not. Composite states are not required for
activity graphs (wf [2] for PseudoState, p 2-166).

No Data Available