XMI12 — XMI handling of type info for CORBA any -- too complex

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