XMI 1.2 NO IDEA Avatar
  1. OMG Issue

XMI12 — Miss-stated XMI compliance points.

  • Key: XMI12-64
  • Legacy Issue Number: 3887
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There are a number of problems with the XMI compliance statements:

    1) These statements all refer to specific XMI documents and XMI DTDs.
    There are no compliance statements for tools that generate DTDs and
    documents. Not even a mention that they might exist.

    2) XMI DTD compliance -

    • DTD generation assumes a MOF meta-model, yet there is not
      of input meta-models. Does this mean that all DTDs must be
      equivalent? (Obviously not ... but you could read the statements
      as requiring that.)
    • The third bullet point refers to "one of the rule sets in Chapter
      6". First, there are no rulesets in Chapter 6 (they are in
      7). Second, what happens if the rule sets give different
      entities? Third, within one ruleset, does the EBNF or the
      code take precedence in the event of a contradiction?
    • The third bullet includes "content multiplicities" as one of the
      items that must be identical in the expanded DTD. Yet the spec
      says that multiplicities are optional (and is inconsistent in the
      DTD rulesets; EBNF versus pseudo-code.)
    • When comparing a DTD against a reference DTD to determine if it
      is compliant, what else must be considered as an "input"? For
      instance, for a given meta-model, an XMI DTD generated using
      "fixed" data typing is clearly not equivalent to one generated
      using the "complete" approach. So how do you measure compliance?

    3) XMI document compliance -

    • No mention of input meta-data. Must all documents be the same?
    • How do you measure compliance when comparing two XMI documents
      produced with different data type mappings?

    4) Usage compliance -

    What is this statement trying to say? That a tool is XMI compliant
    if it complies to the XML recommendations?

    The bulleted point makes no sense as a "condition" under which XMI
    documents must be used ...

    5) XMI MOF subset optional compliance -

    Apparently, this is trying to make it "optional" to transmit complete
    MOF meta-models in an "XMI for MOF" document.

    • The XMI spec has no business making this sort of statement. Such
      statements are the sole business of the MOF spec ... and the MOF RTF.
    • These are stupid restrictions anyway. A MOF implementation that only
      supports the XMI MOF subset is not going to be able to exchange
      meta-models with one the supports the full MOF Model.

    6) XMI DTD optional compliance -

    • The wording is horribly vague; for example

    "XMI DTDs optionally conform to ... DTDs may support ... X .. or Y"

    A lawyer would have a field day with this!

    • The first bullet point says: "The definition of XML entities within DTDs
      are suggested ...". This is not a compliance point. It is a vague
    • The second bullet says: "Either all incomplete rules or no incomplete
      rules should be supported". Then it says "Support for incomplete models
      is an optional addition to the mandatory support for complete models".

    a) Isn't this a contradiction? Doesn't the first sentence mean that
    support for complete models is optional? Or does it mean something

    b) Statements of non-optional functionality in this section are
    misplaced. The last part of the last statement belongs in 11.2.1

    • The third bullet could be read as meaning that DTDs don't need to
      support either mapping.
    • The fourth bullet doen't make sense. What does "role" mean?

    7) XMI Document optional compliance -

    In general, how does an XML document "support" something?

    • Bullet 1 is not a compliance point ... it is a weak recommendation.
    • Bullet 2 is meaningless, given that "production" and "processing" of
      XMI documents is apparently not covered by the earlier mandatory
      compliance points.
    • Bullets 3 & 4 leave open the interpretation that a compliant DTD
      may conform to neither option.
    • Bullet 5 – see Bullet 5 comments for DTD optional compliance

    8) Usage optional compliance -

    I don't think that the XMI spec has any business telling (optionally or
    not) an implementor what XML parser APIs to use. We shouldn't even be
    making recommendations. This is completely outside of the scope of the
    XMI spec.

  • Reported: XMI 1.1 — Thu, 21 Sep 2000 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:11 GMT