XMI 1.2 NO IDEA Avatar
  1. OMG Issue

XMI12 — Encoding of "any" values in XMI

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

    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

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

  • Reported: XMI 1.1 — Mon, 16 Oct 2000 04: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