XMI 1.2 MAILINGLIST Avatar
  1. OMG Issue

XMI12 — XMI 1.2: Missing class scope in <7m:AttName>, pp. 6-6?

  • Key: XMI12-15
  • Legacy Issue Number: 4849
  • Status: open  
  • Source: HiQ ( Thomas Schaumburg)
  • Summary:

    Given a model "Acme" consisting of a class "Wiz", with a string-valued
    attribute "name", two types of model instance encoding are possible. Either
    this, using the <8a:ContentElement> production:

    <Acme:Wiz>
    <Acme:Wiz.name>foo</Acme:Wiz.name>
    </Acme:Wiz>

    or this, using the <7i:DataValueAtt> production:

    <Acme:Wiz name="foo"/>

    At best, the lack of a namespace and class scope identifier in the last
    example is inconsistent. But I suspect that the inclusion of a class scope
    in the former is intended to support instances implementing classes with an
    overlap in attribute names - e.g.:

    // The Acme model:
    class Base

    { attribute String name: }

    class Derived: Base

    { attribute String name; }

    (I'm not familiar enough with the MOF to know if this is allowed, but it
    appears to be the only possible rationale for scoping attribute names in the
    <8a:ContentElement> production)

    Using the <8a:ContentElement> production, a "Derived" instance is easily
    represented:

    <Acme:Derived>
    <Acme:Derived.name>foo</Acme:Derived.name>
    <Acme:Base.name>bar</Acme:Base.name>
    </Acme:Derived>

    However, using the <7i:DataValueAtt> production, things get ambiguous:

    <Acme:Derived name="foo"/>

    Which "name" value is being specified here? Base.name or Derived.name?

    If the XML atrribute names were scoped, this would not be a problem:

    <Acme:Derived Acme:Derived.name="foo" Acme:Base.name="bar"/>

  • Reported: XMI 1.1 — Wed, 20 Feb 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT