XMI12 — Miss-stated XMI compliance points.

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
  mention
  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
  Chapter
  7). Second, what happens if the rule sets give different
  expanded
  entities? Third, within one ruleset, does the EBNF or the
  pseudo-
  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
  recommendation.

• 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
else.

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.