XMI12 — Encoding of "any" values in XMI

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