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)
Currently, the TypeCode information for an 'any' can be represented in a
number of ways according to 188.8.131.52 & 184.108.40.206:
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 220.127.116.11). [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
XMI.CorbaTypeCode xmi.idref="some id" /
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.