XMI 1.2 NO IDEA Avatar
  1. OMG Issue

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

  • Key: XMI12-125
  • Legacy Issue Number: 4045
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    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.

  • Reported: XMI 1.1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close with no action because of updates to MOF 1.4 datatypes

  • Updated: Fri, 6 Mar 2015 20:59 GMT