XML Metadata Interchange Avatar
  1. OMG Specification

XML Metadata Interchange — All Issues

  • Acronym: XMI
  • Issues Count: 35
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
XMI12-108 General inconsistencies between EBNF and pseudo-code in Chapter 7 XMI 1.1 XMI 1.2 Resolved closed
XMI12-107 Element name based on feature instead of class XMI 1.1 XMI 1.2 Resolved closed
XMI12-100 Question of XML element declarations XMI 1.1 XMI 1.2 Resolved closed
XMI12-99 "Define ""short name""" XMI 1.1 XMI 1.2 Resolved closed
XMI12-103 Use of UUIDs and MOF UUIDs needs expansion. XMI 1.1 XMI 1.2 Resolved closed
XMI12-102 OCL and pseudo-code not updated XMI 1.1 XMI 1.2 Resolved closed
XMI12-97 Clarify multiplicity in the XML element declaration. XMI 1.1 XMI 1.2 Resolved closed
XMI12-96 Clarify multiplicity in the XML element declaration. XMI 1.1 XMI 1.2 Resolved closed
XMI12-106 Nested classes XMI 1.1 XMI 1.2 Resolved closed
XMI12-105 Backwards compatibility XMI 1.1 XMI 1.2 Resolved closed
XMI12-104 MOF and UML tagged value alignment. XMI 1.1 XMI 1.2 Resolved closed
XMI12-95 Clarify of fixed DTD declarations requirement. XMI 1.1 XMI 1.2 Resolved closed
XMI12-101 OCL and pseudo-code not updated XMI 1.1 XMI 1.2 Resolved closed
XMI12-98 Pseudo-code for GetReferenceMultiplcity needs updating. XMI 1.1 XMI 1.2 Resolved closed
XMI12-119 How does an XMI document represent multi-valued attribute values? XMI 1.1 XMI 1.2 Resolved closed
XMI12-118 More multiplicity inconsistencies in DTD ruleset 1 XMI 1.1 XMI 1.2 Resolved closed
XMI12-120 Encoding of "any" values in XMI XMI 1.1 XMI 1.2 Resolved closed
XMI12-122 Encoding a union value that has no field value. XMI 1.1 XMI 1.2 Resolved closed
XMI12-121 DTD productions for names of Classes in nested Packages XMI 1.1 XMI 1.2 Resolved closed
XMI12-111 Why do we need 3 XMI DTD rulesets? XMI 1.1 XMI 1.2 Resolved closed
XMI12-110 Multiplicities inconsistency in the DTD rulesets XMI 1.1 XMI 1.2 Resolved closed
XMI12-114 Which Classes doe PkgClasses include? XMI 1.1 XMI 1.2 Resolved closed
XMI12-113 Description of ClassReferences and ClassCompositions productions XMI 1.1 XMI 1.2 Resolved closed
XMI12-117 DTD attributes for AssociationEnds in un-referenced Associations XMI 1.1 XMI 1.2 Resolved closed
XMI12-116 Does PkgContents include XMI.extension? XMI 1.1 XMI 1.2 Resolved closed
XMI12-115 Does PkgPackages contain nested Packages from super-Packages? XMI 1.1 XMI 1.2 Resolved closed
XMI12-109 Multi-valued Attributes in the simple DTD ruleset XMI 1.1 XMI 1.2 Resolved closed
XMI12-112 Inconsistencies in ClassElementDef for DTD ruleset 1 XMI 1.1 XMI 1.2 Resolved closed
XMI12-94 P 9-175, question regarding EBNF XMI 1.1 XMI 1.2 Resolved closed
XMI12-128 Explain Possible Uses of Entity Definitions in XMI DTDs XMI 1.1 XMI 1.2 Resolved closed
XMI12-126 Completeness of TypeCode and Any support XMI 1.1 XMI 1.2 Resolved closed
XMI12-125 XMI handling of type info for CORBA any -- too complex XMI 1.1 XMI 1.2 Resolved closed
XMI12-124 Representing object references in an XMI document XMI 1.1 XMI 1.2 Resolved closed
XMI12-123 Representing type information for CORBA anys XMI 1.1 XMI 1.2 Resolved closed
XMI12-127 Update XMI 1.2 to reflect MOF 1.4 updates XMI 1.1 XMI 1.2 Resolved closed

Issues Descriptions

General inconsistencies between EBNF and pseudo-code in Chapter 7

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

    1) The pseudo-code specification in 7.2.2 contains embedded EBNF, that
    is quite distinct from the earlier EBNF. It uses different lexical
    conventions (e.g. 'S' and 'Q' meta-syntactic elements), the productions
    have different numbering, and the non-terminal symbols are different.
    The two sets of EBNF should be identical.

    2) All "," comma separated lists defined in the pseudo-code should be
    replaced with "|" separated lists.

    3) Multiplicities for XML elements affect the DTD according to the
    pseudo-code, but not according to the EBNF. The text of 6.6.5 (last
    para) implies that the EBNF is correct. Fix the pseudo-code.

    4) In the pseudo-code, it is unclear whether the phrase "parent Package"
    means the Package containing the given Package, or a Package this
    Package inherits from, or both. For example, in the description and
    pseudo-code for GetClassLevelAttributes.

  • Reported: XMI 1.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Element name based on feature instead of class

  • Key: XMI12-107
  • Legacy Issue Number: 3854
  • Status: closed  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    Would allow more flexible customization of XMI serialization by supporting both of the most common serialization preferences.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close, no change

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

Question of XML element declarations

  • Key: XMI12-100
  • Legacy Issue Number: 3830
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Question if both XML element and XML attribute declarations are meant to be defined. No change. The declarations present in the text are intentional.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    No change. The declarations present in the text are intentional

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

"Define ""short name"""

  • Key: XMI12-99
  • Legacy Issue Number: 3829
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "Section 6.6.1, the first sentence of the first full paragraph on p-67 uses the term ""short name""" "Accept. Omit the reference to ""short name."" "

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Accept. Replace "short name" with "name".

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

Use of UUIDs and MOF UUIDs needs expansion.

  • Key: XMI12-103
  • Legacy Issue Number: 3833
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    . Item 20/2924 of XMI 1.1 RTF was not fully completed. Apply to sections 6.5.1 and rule 7e of document production. Accept. Clarify the use of UUIDs.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

OCL and pseudo-code not updated

  • Key: XMI12-102
  • Legacy Issue Number: 3832
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The OCL and pseudo-code ""maintained for reference"" are not updated to XMI 1.1. Example, Section 9.5.4" .

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Clarify multiplicity in the XML element declaration.

  • Key: XMI12-97
  • Legacy Issue Number: 3825
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The reference in the ""except"" clause of ""Association Specification"" in section 6.6.6 is not consistent with ""Containment Specification"" in section 6.6.7." Accept. The except clause will be dropped.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    The except clause will be dropped.

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

Clarify multiplicity in the XML element declaration.

  • Key: XMI12-96
  • Legacy Issue Number: 3824
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The reference in the ""except"" clause of ""Association Specification"" in section 6.6.6 is to text that was removed." Accept. The except clause will be dropped.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    The except clause will be dropped

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

Nested classes

  • Key: XMI12-106
  • Legacy Issue Number: 3853
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    Nested classes currently do not follow the even/odd standard progression of element nesting. Add an intermediary element.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Close, no change

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

Backwards compatibility

  • Key: XMI12-105
  • Legacy Issue Number: 3838
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The XMI RTF meeting in Mesa had consensus that the extra declarations for element attributes for backwards compatibility with XMI 1.0 are no longer needed.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

MOF and UML tagged value alignment.

  • Key: XMI12-104
  • Legacy Issue Number: 3834
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Question if both MOF and UML were defining the same tag values for initialValue. No change. This is a DTD initialValue which differs from UML's initial value.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    No change. This is a DTD initialValue which differs from UML's initial value

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

Clarify of fixed DTD declarations requirement.

  • Key: XMI12-95
  • Legacy Issue Number: 3823
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Fixed DTD declarations for CORBA need to be clarified in 6.2.2 compared to 6.5.18 and 7.5. "Accept - see AB issues sheet. Clarify to indicate only the required elements in section 7.5."

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

OCL and pseudo-code not updated

  • Key: XMI12-101
  • Legacy Issue Number: 3831
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    "The OCL and pseudo-code ""maintained for reference"" are not updated to XMI 1.1. Example, Section 7.2.2" Accept. The OCL and pseuo-code will be removed.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Pseudo-code for GetReferenceMultiplcity needs updating.

  • Key: XMI12-98
  • Legacy Issue Number: 3826
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Multiplicity should match 6.6.2. EBNF takes precedence. Accept. The Pseudo-code will be dropped.

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete pseudo-code.

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

How does an XMI document represent multi-valued attribute values?

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

    How does an XMI 1.1 document represent multi-valued attribute values?
    For example, suppose we have an attribute "foo" with type == 'string'
    and multiplicity of '0..*'. How do you represent this attributes
    value when it contains multiple strings; e.g.

    {'string1', 'string2'}?

    There seem to be three different answers according to Chapter 9.
    The EBNF on page 9-205 is unclear, but it seems to be saying that it
    would look something like:

    <pkg.cls.foo>
    <pkg.cls.foo> string1 </pkg.cls.foo>
    <pkg.cls.foo> string2 </pkg.cls.foo>
    </pkg.cls.foo>

    though the following could be valid also:

    <pkg.cls.foo>
    <pkg.cls.foo> string1
    <pkg.cls.foo> string2 </pkg.cls.foo>
    </pkg.cls.foo>
    </pkg.cls.foo>

    The EBNF on pages 9-217 and 9-221 seems to say:

    <pkg.cls.foo> string1 string2 </pkg.cls.foo>

    This leaves us with a problem in distinguishing {'string1', 'string2'}

    from

    {'string1 string2'}

    .

    On OCL on pages 9-217 and 9-221 seems to say:

    <pkg.cls.foo>
    <XMI.seqItem> string1 </XMI.seqItem>
    <XMI.seqItem> string2 </XMI.seqItem>
    </pkg.cls.foo>

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

More multiplicity inconsistencies in DTD ruleset 1

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

    There are inconsistencies between the EBNF and pseudo-code with respect
    to handling of multiplicities in EBNF productions 6f, 9c, 9d and 12c.
    Typically the EBNF us a '|' separated list and the pseudo-code uses ','
    or a mixture of '|' and ','.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

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
    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".

  • 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

Encoding a union value that has no field value.

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

    Consider the following CORBA union type:

    union Foo switch(long)

    { case 1: boolean one; case 2: char two; }

    ;

    The production rules in 9.5.7.4 and 9.5.9.9 do not say how a "Foo" value
    should be encoded in an XML document when the discriminator is (say) zero.
    (The OCL for 9.5.9.9 will give an exception in CORBA 2.3 in this case.)

    Should the Foo value be encoded in XMI as:

    <XMI.unionDiscrim>0</XMI.unionDiscrim>

    or

    <XMI.unionDiscrim>0</XMI.unionDiscrim>
    <XMI.field></XMI.field>

    or something else?

  • Reported: XMI 1.1 — Fri, 27 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

DTD productions for names of Classes in nested Packages

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

    There is an inconsistency between the EBNF and pseudocode that
    generates DTD element declarations for Classes. According to
    the EBNF (production 6a) the element name is the "name of Class"
    preceded by an optional namespace. According to the EBNF, the
    element name is a the qualified Class name.

    There are two issues:

    1) If we follow the EBNF and use an unqualified name, there is
    a risk of name collision when there are Classes in nested Packages.

    2) If we follow the pseudo-code, we lose the namespace prefix.

  • Reported: XMI 1.1 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

Why do we need 3 XMI DTD rulesets?

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

    The XMI spec currently defines 3 rulesets for generating DTDs for
    meta-models. The rulesets give different DTDs, but they are all intended
    to match (i.e. be capable of validating) the document production rules
    in Chapter 9.

    Given that the 3 kinds of DTDs are equivalent, why do we need them all?
    The point of XMI is the interchange of metadata, not the generation of
    pretty DTDs. Indeed, the XMI DTD compliance section (11.2.1) makes
    it clear that any DTD that expands to the same form is compliant.

    I suggest we just delete the compact DTD rulesets, and leave the
    implementation of "pretty" DTDs as an exercise for the implementor
    to undertake ... or not. The alternative is that we must ensure that
    any changes / corrections are made to the simple ruleset are made to
    the other two rulesets.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Remove DTD rule sets 2 and 3 in chapter 4

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

Multiplicities inconsistency in the DTD rulesets

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

    The pseudo-code in DTD ruleset 1 for Attributes and References generates
    DTDs in which '?', '+' or '*' may be generated depending on the
    element's
    multiplicity. The earlier EBNF uses '*' only.

  • Reported: XMI 1.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Which Classes doe PkgClasses include?

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

    There is a discrepancy between the text describing EBNF production 9e
    and the corresponding pseudo-code. According to the EBNF description,
    only Classes directly contained by this Package or Classes directly
    contained by this Package's direct and indirect super-Packages are
    included. According to the pseudo-code (e.g. GetPackageClasses on
    page 7-113), Classes from containing Packages and their super-Packages
    are also included.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

Description of ClassReferences and ClassCompositions productions

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

    This relates to productions in DTD ruleset 1

    1) In 6f, what on earth is "an ownedElement of a Class"? This is not
    a recognisable MOF meta-modelling concept.

    2) In 6f, what subclasses need to be included? Those declared in
    this
    Package? In nested Packages? In Packages that import, cluster
    or inherit this Package? More?

    3) In 6e, how come you don't also include names of subclasses of the
    types of the References?

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

DTD attributes for AssociationEnds in un-referenced Associations

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

    According to EBNF productions 11c & 1a, an AssociationEnd in an
    un-referenced
    Association is represented as "%XMI.element.att;%XMI.link.att".
    According
    to the pseudo-code, it is just "%XMI.link.att".

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Does PkgContents include XMI.extension?

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

    This relates to DTD ruleset 1 production 9c. According to the EBNF, the
    XMI.extension element is present in the Package contents. According to
    the pseudo-code (p 7-100) it is not included.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Does PkgPackages contain nested Packages from super-Packages?

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

    There is a discrepancy between the text describing production 9g of DTD
    ruleset 1, the pseudo-code for getContainedPackages and its description.
    The first two say that PkgPackages contains any nested Packages from
    super-Packages, but the description for getContainedPackages does not
    mention this.

    Also, it is not crystal clear what "nested Packages" means in 9g (and
    by extension in other places). It should mean all Packages that
    are directly or indirectly contained by a Package., but this needs to
    be spelled out somewhere.

  • Reported: XMI 1.1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

Multi-valued Attributes in the simple DTD ruleset

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

    The EBNF (4d, 4f) and pseudo-code for Attribute contents in the simple
    DTD ruleset seem to support multi-valued Attributes in different ways.
    In the EBNF, "attribute contents" have an enclosing "( )*" in the two
    cases that matter. By contrast, in the pseudo-code, the "( )*" 's are
    sometimes present and sometimes absent.

    I think the EBNF is probably correct.

    There are also some minor meta-syntax errors in the pseudo-code;
    e.g. missing quotes.

  • Reported: XMI 1.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

Inconsistencies in ClassElementDef for DTD ruleset 1

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

    The EBNF seems to be generating "|" separated lists for the
    contents of a Class, but the pseudo-code generates "," separated lists.
    This seems to occur with the attribute and reference lists as well
    as the overall contents list.

    In the pseudo-code, 'GetAllReferences' returns all References, but the
    EBNF excludes those References whose exposedEnd is composite.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete OCL and pseudo-code

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

P 9-175, question regarding EBNF

  • Key: XMI12-94
  • Legacy Issue Number: 3822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the XMI spec, on page 9-175, it says that EmbeddedObject serves as an alternative to ObjectAsElement for cases where an identifier is not required (i.e. the object participates in no links). However, the EBNF says that an ObjectAsElement is included between the tags (The OCL uses ObjectContents). Can I assume that this is a problem with the XMI spec, and that it should be ObjectContents?"

  • Reported: XMI 1.1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    Removal of obsolete pseudo-code (section 6.4).

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

Explain Possible Uses of Entity Definitions in XMI DTDs

  • Key: XMI12-128
  • Legacy Issue Number: 4432
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    Since the DTD rule sets 2 and 3 have been removed, along with the
    pseudo-code, a discussion of the possible uses of entity definitions in XMI
    DTDs should be included in the specification to help people implement XMI
    DTD generation.

  • Reported: XMI 1.1 — Mon, 30 Jul 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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

Completeness of TypeCode and Any support

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

    The "fixed elements" for XMI.CorbaTypeCode in sections 6.5.18 & 7.5 are buggy.
    There is no element for the "unsigned long long" TypeCode, and the element
    for the "fixed" TypeCode is not allowed in XMI.CorbaTypeCode.

    In addition, we should consider extending XMI's support of TypeCodes and
    Anys to cover the "value" types added in CORBA 2.3. [We don't need to
    handle Attributes with "value" types at this stage because MOF doesn't
    support this in meta-models.]

    Editorial: The "fixed" DataType DTD elements appear BOTH in section
    6.5.18 and in section 7.5. Could we replace the former with a reference
    to the latter?

  • Reported: XMI 1.1 — Thu, 14 Dec 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

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

Representing object references in an XMI document

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

    Suppose that a meta-model is declared as follows:

    package Foo {
    class Bar

    { attribute CORBA::Object baz; }

    ;
    };

    According to the XMI document production rules, the value of the "baz"
    attribute should be encoded using the ObjectReference production (9.4.5.2).
    This says that if the object is part of the model (e.g. an instance of
    some Class defined by the meta-model), the value is encoded as:

    XMI.reference xmi.idref="some_id" /

    Otherwise it is encoded as

    XMI.reference href="some_URL" /

    Unfortunately, the latter does not work because there is no legal URL
    representation for a CORBA Object reference, and you can't represent
    a CORBA Object reference in some other XMI document.

    I think the fix is to provide a third alternative:

    XMI.reference stringified-CORBA-IOR /XMI.reference

  • 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

Representing type information for CORBA anys

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

    If I understand 9.5.7.10 correctly, it says that the type information for an
    Any may be partly or fully represented by "xmi.kind", "xmi.id" and "href" XML
    attributes of the XMI.any element. However, according to the fixed element
    declarations in 6.5.18, the "XMI.any" element cannot have an "xmi.kind" or (I
    think) "xmi.id" attributes. Instead, it has attributes "href", "xmi.idref",
    "xmi.name" and "xmi.type".

    Which attributes should be used?

  • 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

Update XMI 1.2 to reflect MOF 1.4 updates

  • Key: XMI12-127
  • Legacy Issue Number: 4417
  • Status: closed  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    MOF 1.4 has had the final RTF votes. There are changes to MOF 1.4 that
    result in updates to XMI 1.2. In particular, the data type simplification
    in MOF 1.4 will lead to improvements for XMI 1.2.

  • Reported: XMI 1.1 — Mon, 23 Jul 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.2
  • Disposition Summary:

    see above

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