Issues for XML Metadata Interchange (XMI) RTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2924: Element Identification Attributes
Issue 3827: Reference to deleted text on fully qualified names.
Issue 3835: MOF and UML tagged value alignment.
Issue 3836: Documentation of References in section 6.6
Issue 3837: Examples with references confusing.
Issue 3839: AssociationEnds without references
Issue 3840: Open DTD content for subclasses
Issue 3841: Appendix C example
Issue 3842: Typo in applicability scenarios
Issue 3843: XMI cross-version compatibility
Issue 3844: Usage of XMI for GIS ISO 19118/TC211
Issue 3845: Example C Multiplicity
Issue 3846: QName for XML attribute values
Issue 3847: Additional examples
Issue 3848: Containment as links
Issue 3849: Specifying Attributes vs Elements
Issue 3850: Allow suppression of reference serialization
Issue 3851: XMI.reference suppression
Issue 3852: XMI.content declaration
Issue 3863: Status of pseudo-code in Chapter 7
Issue 3864: XMI Tags
Issue 3865: DTD production clarifications for nested Packages
Issue 3867: Bug in pseudo-code for PackageDTD
Issue 3878: Section 6.12 needs rewriting.
Issue 3879: Editorial: remove unnecessary hitorical references.
Issue 3881: The UML and MOF DTD appendices are poor examples.
Issue 3882: DTD generation rules for composed Packages.
Issue 3883: The "complete" approach to XMI data types must be optional
Issue 3884: DTD generation for DataTypes with typecode.kind == tk_alias
Issue 3886: Editorial: Fix up the cross-references.
Issue 3887: Miss-stated XMI compliance points.
Issue 3889: XMI MOF Subset" optional compliance point.
Issue 3890: DTD rules unclear for attributes of subclasses.
Issue 3896: "Inputs" that define an XMI metadata interchange format.
Issue 3901: DTD element content and multiplicities versus compliance.
Issue 3936: How to represent a "null" for a Class-valued Attribute?
Issue 3941: EmbeddedObject is misused
Issue 3942: Document production rules for "un-Referenced" Associations.
Issue 3945: Garbled descriptions in ObjectAsElement (page 9-204)
Issue 3949: Association elements when no immediate references
Issue 3967: Include Derived Attributes and References of Derived Associations
Issue 4006: EBNF incomplete for Attributes with complex types
Issue 4032: Minor bug / typo in handling of References
Issue 4046: Encoding of strings and characters in XMI documents
Issue 4062: Reconsider XML attribute encoding of values in XMI 1.1
Issue 4063: XML attribute encoding of values underspecified
Issue 4067: Anomalies with References and ordered Associations.
Issue 4068: bi-directional References and redundancy
Issue 4086: Inconsistencies for classifier-level Attributes
Issue 4134: Composition Association problems
Issue 4212: Production by Package Extent Example in 00-12-05
Issue 4215: UML: Using public identifiers to denote DTDs
Issue 4248: Include derived attributes and references in rule 6d in DTD production
Issue 4505: XMI document production rule 7c issue
Issue 4580: Section 5.3 still uses old datatypes
Issue 4581: Incomplete rules for non-Primitive Datatype values
Issue 4582: Example in A.5 is misleading
Issue 4596: Directory structure for OMG standard XMI documents and DTDs
Issue 4598: Problems with section on Linking
Issue 4599: Specification addresses only generation not consumption (medium)
Issue 4600: Clarify that references to external documents can be virtual (minor)
Issue 4601: Effect of xmi.import is unclear (medium)
Issue 4602: Examples are instances of non-MOF metamodels (medium)
Issue 4603: Example 4 in A.5 is obscure (minor)
Issue 4604: Nonexistent '<ElementContent>' used (minor)
Issue 4605: Tool interchange recommendation insufficient (major)
Issue 4606: Adoption of XLink specification (minor)
Issue 4646: XMI: No way to specify the meta-meta-metamodel
Issue 4647: Appendix A, Example , the example is not valid UML.
Issue 4652: XMI does not document the tag used to determine XML Namespace
Issue 4702: Unclear URI format
Issue 4703: UML conversion to MOF out of scope
Issue 4704: Outmoded use of '|' as separator
Issue 4705: Unclear software compliance - see also issues 3887 and 3889
Issue 4721: OMG XML Metadata Interchange issue
Issue 4790: XMI issue - xmi.exporterId inconsistently used and undefined
Issue 4791: [xmi] xmi.label / xmi:label
Issue 4817: MOF structured types missing from XMI 1.2
Issue 4818: What is the idea of encoding package contents?
Issue 4819: What IS this "General Datatype Mechanism" anyway?
Issue 4847: Problem with namespaces
Issue 4849: XMI 1.2: Missing class scope in <7m:AttName>, pp. 6-6?
Issue 4900: propose a new tag to be applied to metamodels
Issue 4944: org.omg.xmi.enumerationUnprefix
Issue 5300: XMI issue - referenceless composition does not export components
Issue 5305: XMI 1.2 Issue - Association elements with references
Issue 5545: "3.6.1 Namespace Qualified XML Element Names"
Issue 5546: 3.6.4 Inheritance Specification
Issue 5547: 3.6.5 Attribute Specification
Issue 5548: 3.6.4 Inheritance Specification
Issue 5549: General question to "3.6.4 Inheritance Specification"
Issue 5770: Invalid example model encoding XML
Issue 5883: DTD's (01-04-03) for XMI 1.2
Issue 5940: Empty Fragment Identifier in Link
Issue 5946: Urgent XMI 2.0 issue: XML Schema Production

Issue 2924: Element Identification Attributes (xmi-rtf)

This is in regard to section 6.5.1 of 98-10-05 which has the following declaration at the beginning:

<!ENTITY % XMI.element.att
’xmi.id ID #IMPLIED
xmi.label CDATA #IMPLIED
xmi.uuid CDATA #IMPLIED ’ >

Since MOF 1.3 makes it mandatory that ref_mof_id return a unique id for a metaobject it seems that xmi.id ID should be required rather than implied.

106	resolved	clarification	minor	Dave Frankel	Reference to deleted text on fully qualified names.	"Section 8.3.1 on p. 8-189, the second paragraph begins with:  ""Note that all names in XMI are fully qualified, based on the MOF description of their metamodel.""  This appears to contradict 6.6.1"	Accept.  The sentence will be dropped.

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.

Go through EBNF and be sure that each rule is documented in section 6.6.	Accept.

"The example for document serialization uses references with different names than the assocation ends, which is confusing (although legal)."	Accept.  Create simpler examples.

Improvements to grammar for AssociationEnds that have no references.	

"Since DTDs are not extensible for subclasses, add the ANY element to containment content for future subclasses.  See issue 126 for another solution."	

Portions of the example are inconsistent

"page 4-33, 4.3.2 Benefits of using XML, . The cost ...WYSYWIG editors.  may be WYSIWYG ?"	

State the differences between versions and the modifications needed for a sender/receiver to handle previous versions.	

Identify and resolve issues for using XMI for data interchange of Geospatial System Interoperability data in ISO 19118/ ISO/TC211

Clarify if example should show multiplicity as structure or object.	

XML Namespaces includes a Qname for XML attributes that allows cross-document references.  Supplements XML element href cross-file links.	

More examples would clarify the specification.	

	Requiring containment to use nested elements creates DTDs with large copydowns.  Containment using attribute references would simplify DTDs as an option to be stated in the model.	

	Allow the model to specify serialization as XML attributes or XML elements.  Removes duplicate declarations in DTDs (and Schemas when available).  Requires issue 124 to support cross-doc links from XML attributes.	

Allowing the suppression of reference serialization on one side of an association reduces redundancy of information.  Allows one side of a cross-file relationship to be updated without requiring a write update to the other side.  Declaration is made in the model.

Allow the model to specify whether XMI.reference is allowed.  Reduces size and simplifies DTDs for XML elements.  Reduces mixed content from DTDs.  Default would be to turn XMI.reference use off.	

Allow the content of XMI.content to be declared in the model instead of ANY for more readily validated and edited documents.	

It is not clear whether or not the pseudo-code and accompanying text in 
7.2.2, 7.2.3 and so on is intended to be normative.

Chapter 7.1 states in the second paragraph:

  "... In XMI 1.1, these rule sets are stated formally in EBNF.  The
   pseudo-code that was used to state these rules in XMI 1.0 remains
   for reference and explanatory value."

This implies that the pseudo-code is non-normative.  But it doesn't say
so clearly.

It is necessary to clarify this point in order to decide how to deal
with the (numerous) inconsistencies between the EBNF and the 
pseudo-code.

The XMI 1.1 spec makes reference to a number of XMI specific Tags.
Unfortunately, they are underspecified, and have names that do not
conform to the MOF Tag naming conventions given in the MOF 1.3 spec
in section 3.4.23.

To fully specify a Tag, you need to define the following:

  1)  The full tag name; e.g. "org.omg.xmi.data_type".  (Note: 
spelling!)

  2)  The metamodel class(es) that the Tag may be attached to; e.g. 
Model::Class

  3)  The CORBA type and number of "values" (i.e. parameters) that a Tag
      instance may have.

  4)  The meaning of the Tag in all contexts that it is meaningful.
  
Finally, it would be a good idea if all of the XMI Tags were defined in 
a
separate section ... possibly with cross references to the places where
they are used in production sets.

When a Package contains another Package:

  a)  If the containing Package contains an Association which is only
referenced in the contained Package, should the containing Package treat
it as an unreferenced or referenced Association?

  b)  If the contained Package contains a child Class which inherits 
from a
parent Class in the containing Package, should the DTD for the 
containing
Package allow instances of the child Class?

The pseudo-code for PackageDTD on p. 7-95 is inconsistent with the
EBNF. The EBNF states the requirements for when to generate a
CompositionDTD for an Association as follows: "The composition element
is generated for each Reference in the Package which has an exposedEnd
whose aggregation is composite." This means that if the one of the
AssociationEnds of a Association has an composite aggregation and the
referencing Reference's exposedEnd points to that same AssociationEnd,
only then should the composition element (CompositionDTD) be created.

The pseudo-code makes a similar, but weaker requirement.  It requires
only that an Association contains an AssociationEnd that has a composite
aggregation. In fact, this would create duplicate declarations of the
Reference XML element if the referencedEnd of a Reference has a
composite aggregation, which is clearly wrong.

Section 6.12 deals with the mapping of meta-model DataTypes to XMI.  
A key requirement of XMI was that XMI producer and consumer software
could generated from a meta-model, or written to be "table driven" using
the meta-model as input.  Such software has to be compatible with any
hand-built XMI software built according to the spec.  The problem with
Section 6.12 (as written) is that it seems to break this requirement.
(See point 4 below).

By saying "This general solution ...", section 6.12 seems to try to
define a mechanism for tailoring XMI data type mappings.  Unfortunately,
it is woefully inadequate as a specification.  It is unimplementable as
written.

The XMI 1.1 specification contains numerous references to the way that 
things
used to be in XMI 1.0, scattered throughout the document.  For example,
on page 6-55, we see:

  "xmi.uuidref:  This attibute is no longer used in XMI 1.1.  In XMI 
1.0, its
   use is described in the following paragraph".

It is not normal for OMG specs to include this kind of material.  
Unless
there is a good reason for retaining it, it should be removed.  

The only justification for this kind of material is if there is a
converted effort to maintain backwards compatibility; e.g. the CORBA
core describes multiple versions of the IIOP formats.  

Section 6.11 of the XMI 1.1 spec deals with the UML DTDs generated using
XMI.  Appendix A contains the complete UML 1.1 DTD.  Appendix B contains
the MOF 1.1 DTD.

If this hasn't happened already, responsibility for these DTDs should 
be transferred to the their respective RTFs.  The MOF and UML DTDs 
should be removed from the XMI spec.

In my opinion, the UML and MOF DTDs are both too large to be good 
examples
for XMI.  We should come up with a set of smaller examples that 
illustrate
how XMI works with complex meta-models, and how you use the various 
"bells
and whistles" for tailoring the XMI mappings.

The DTD generation rules do not adequately cover Package importing, 
clustering and inheritance.

 1)  There are no references to clustering anywhere in the DTD 
     generation rules.

 2)  There are allusions to the XMI.import element in Chapter 6 but no
     proper explanation of how it is used.  Other points need to be
     clarified.  For example, I can't work out how the DTDs allow you
     to represent an instance of metamodel Class which has an Attribute 
     whose type is an imported Class.

 3)  Package inheritance seems to be covered in the EBNF for DTD
     generation and the corresponding pseudo-code.  However, the
     terminology is loose; e.g. refering to "Packages from which
     this Package is derived" without stating whether "derived"
     refers to the MOF::Model::Generalizes association.

The XMI 1.1 RTF added material to section 6.5.18 to allow XMI DTDs
to be defined (by the metamodeller) that use custom XML elements to
represent data values.  This is the so called "complete" approach,
and is new in XMI 1.1.

The description of the "complete" approach in section 6.5.18 and
elsewhere seems to allow XMI DTDs to be created by hand that cannot
be automatically generated from a meta-model.  This means that the
"complete" approach cannot be implemented by a MOF / XMI vendor
without relying on proprietary extensions; e.g. a proprietary way
of telling XMI generators for import and export tools how to
encode / decode custom data strings.

At a minimum the "complete" approach should be downgraded to an 
optional
XMI compliance point in XMI 1.2  It could be argued that the material 
should not have added in the first place, since:

  1)  adding significant new functionality is beyond the scope of 
      an RTF, and

  2)  incomplete specifications that rely on "magic" or on proprietary
      extensions are forbidden.

The pseudo-code on page 7-97 does not address this case.

There are a number of missing and broken cross-references in 
ad/99-10-02.
For example:

  * the Glossary refers to "MOF 1.x", 

  * the Compliance chapter contains references to [SAX reference],
    [XMI reference] and so on.

  * the Compliance has a cross reference to "Section ." (sic) and
    to "rulesets in Section 6" which should be 7.

And so on.

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.

This compliance point (11.3.1) is worrying.  It means that a compliant
XMI implementation may be capable of transmitting/receiving metadata
described by a legal and meaningful MOF meta-model.  For example, the
MOF Model itself has a number of References where the Reference's name
and the corresponding AssociationEnd have different names.  Thus, XMI
support for the MOF Model is optional.  This is in violation of the 
XMI RFP requirements, and contradicts the intention of other parts of
the spec.

I suggest that the MOF and XMI RTFs jointly review the listed "optional"
MOF features in 11.3.1 with a view to either making them mandatory in
XMI, or removing them from the MOF Model in MOF 1.4.

This issue relates to the description of production 4c of the simple
DTD ruleset on page 7-88.  The text says 

  "If the Class has subclasses, the element name of each of its 
subclasses
   is included in the declaration".

This is ambiguous.

Suppose that we are generating a DTD for a Package P1 that contains C1,
and there is also Package P2 that imports clusters or inherits from P1
and defines C2 as a subclass of C1.  In each case, should the DTD 
generated for C1 in P1 include declarations for C2 attributes, or not?

If yes, how does the generator find out what packages import / cluster
/ subtype P1?  Also, how does XMI deal with addition of (say) a new
importer of P1 after the DTD for P1 has been generated?  (Does it 
break?)

If no, how do I represent in XMI a link in an Association in P1 that
has a C2 instance at one end?

[I can guess some answers to these questions, but that isn't good 
enough.
The spec should cover this Package composition issue here, or there 
should
be a reference to some other part of the spec that deals with it.]

In XMI 1.0, an XMI metadata interchange format (i.e. the XMI DTD and 
associated
encoding rules) was determined solely by the metadata's MOF meta-model.

In XMI 1.1, various additions were made that meant that this is no 
longer
the case.  An XMI 1.1 format now also depends significantly on other
"input parameters".  This includes:

  1)  The XML namespace used to abbreviate element names

  2)  The so called "domain datatype meta-model" and its relations to
      the main meta-model.

  3)  Any custom rules for converting between data values and XML 
strings.

  4)  Whether the format supports complete meta-models or incomplete 
meta-models.

Since differences in any one of these parameters (or the MOF meta-model)
result in non-interoperable XMI formats, it is crucial that 
meta-modellers
define the parameter values, explicitly and clearly.  Without this, 
implementation of "standard" XMI formats is a matter of guesswork.

The XMI spec should say precisely what parameters effect the XMI 
mappings,
and how they should be specified for a "standard" XMI format.

The examples in the XMI spec, and particularly the Appendices should 
state
what parameters have been used.

In XMI 1.0, the DTD generation rules give a DTD that "tightly" specify
the element content and multiplicities for Attributes according to the
meta-model types and multiplicities.  In XMI 1.1, the generation rules
(at least the EBNF version) "loosen" the element content and
multiplicity.

The current XMI conformance rules have the effect that an XMI 1.0 DTD is
not conformant to XMI 1.1.  Is this intentional?  Should 11.2.1 bullet
point 4 be amended to account for different degrees of looseness?

I argue that:

  1)  Tighter DTDs should in general be compliant.  A "tight" DTD that 
      constrains element content to meta-data that matches a meta-model 
      shouldn't be deemed non-compliant.  The real point of XMI DTDs is 
      to ensure supposed XMI documents contain meaningful metadata, as
      far as possible.  It is counter-productive to make it "incorrect" 
      for an XMI DTD generator to do a better job than the templates.

  2)  A specific statement on backwards (in-)compatibility should be 
      added to deal with the sub-cases where XMI 1.0 DTDs are over-
      constrained according to XMI 1.1; e.g. where the XMI 1.0 DTDs
      constrain the order of elements representing Attributes.

Suppose that my meta-model has a Class whose Attribute has another Class
as its value.  How do I represent this attribute in an XMI document when
its value is a null object reference?

According 9.5.4.2, the document should contain something like this:

  <pkg.cls.attr>
    <pkg.othercls xmi.idref="" /> 
  </pkg.cls.attr>

Unfortunately, this doesn't work as the empty string is not legal as an
IDREF value.

As far as I can tell the 9.3 EBNF rules (e.g. production 7h) don't even
consider the case where an Attribute's type is a Class.

Assuming that issue 3822 is resolved as Dave Frankel suggests, we have a
problem with the way that the EmbeddedObject production is used in other
productions; e.g. MvAttributeContents and SvAttributeContents.  In these
cases (and possibly others), EmbeddedObject may generate embedded XML 
for
a Class instance that needs to be referenced (via an xmi.idref) 
elsewhere
in the document.  But the EmbeddedObject production does not include the
necessary "xmi.id" attribute to make this work.

The easiest solution is to get rid of the EmbeddedObject production
altogether, and replace all uses with ObjectAsElement.

The EBNF for an "un-referenced" Association on page 9-206 says that it 
should be represented as follows:

  <...assocname>
    <...assocname.end1name>
      <...class1name xmi.idref="..." />
    </...assocname.end1name>
    <...assocname.end2name>
      <...class2name xmi.idref="..." />
    </...assocname.end2name>
    ...
  </...assocname>

This does not conform to the DTD generated by production 11 on page 
7-93.

There are some sub-productions of ObjectAsElement whose meaning I cannot
fathom.  Specifically ElementAttributes may include a RefValueAtt that
is described as follows:

  The XML attribute for reference contains the XML ID of each referenced
  object.

Is this referring to the rendering of a Reference, or the rendering of
an Attribute whose type is a Class?  In either case, how does this 
square
with the sub-productions of ObjectContents on the next page?  

Or does it mean something else?

The XMI 1.1 Specification says an Association elements is generated only if
there is no reference for the Association.  But if the only references are
defined on subclasses of related types, then links could be created between
objects of the more general type, and those links cannot be passed via XMI
because there is no reference on the general type.  Therefore, the
specification needs to state more precisely that an Association element is
generated in a DTD if it has no reference whose container is equal to the
type of the reference's exposedEnd.

Topic: Include Derived Attributes and References of Derived Associations in
the XML DTD      Production

XMI 1.1 is not clear nor consistent with respect to inclusion of derived
attributes and references of derived associations in the XML DTD
production. As a result, some XMI RTF member believes they should be
included, while some other member believes they should not be included.

To be consistent with MOF, MOF to IDL Mapping, and JMI (Java Metadata API,
a standard being developed under the Java Community Process), XMI should
include derived attributes and references of derived associations in the
XML DTD production.

If not, XMI will limit its usefulness in addition to being inconsistent
with MOF, MOF to IDL Mapping, and JMI. For example, suppose age is a
derived attribute of class Person in some MOF-compliant metamodel. MOF to
IDL Mapping allows one to access or interchange age in IDL or any
programming language that has an IDL mapping. JMI allows one to access or
interchange age in Java. If XMI does not allow one to access or interchange
age in XML, then one would have to use something like XML Binding to Java
in conjunction with JMI to do so. The same goes for references of derived
associations.

Therefore, if XMI does not allow inclusion of derived attributes and
references of derived associations in the XML DTD production, one would
have to use XMI to access or interchange most metadata information in XML
and use something like XML Binding to Java with JMI to access or
interchange derived metadata information in XML. This is simply
unreasonable.

The DTD EBNF for Attributes (e.g. production 4c on page 7-88) does not cover
the more complex DataTypes; e.g. arrays, sequences, structs, unions, TypeCode,
Any, Principal or object reference types. Similarly, the document EBNF for
Attributes (production 8d on page 9-205) fails to say how the corresponding
attibute values should be encoded.

In the description of ReferenceAsElement in 9.5.5.1 on page 9-218, the
spec says:

  "When the Reference's multiplicity has an upper bound greater than one
   ... a lower bound of zero, the reference is checked to see if any values
   exist."

In reality, this check needs to happen >>always<<.  Even in the [1..1] case,
the value may not exist if you are generating XML for an incomplete model.

The document production rules for encoding of strings and characters (9.5.9.23
& 9.5.9.24) need to be clarified.

They need to say how to encode significant whitespace characters so that they
don't get mangled by XML document builders and parsers.  Leading and trailing
whitespace are particularly worrisome.  One possible solution is surround the
entire character or string value with matching quotes, and say that anything
outside of the quotes is significant.

They also need to say that characters and strings are encoded using ISO-10646
(as per 3.1.5).

I want the XMI RTF to reconsider the XMI 1.1 change to the encoding
of simple data type values.  My experience and that of some others
is that this makes implementation of XMI unnecessarily hard.

Discussion:

In XMI 1.0, the rules for encoding simple DataType values were
relatively straightforward:

  *  The value of an Attribute (whose type is a simple type) is 
     represented as the text content of the Attribute's element,
     except for booleans and enums which are represented using
     the xmi.value attribute.

  *  An embedded simple value (e.g. in a any, struct field, etc) is 
     represented the same except that boolean and enum values are
     represented using the XMI.enum element.

This is pretty straightforward ... apart from the inconsistent 
handling of boolean and enum.

In XMI 1.1, the rules changed so that the XMI document producer
could put values of simple DataTypes into the xmi.value attribute.
The purported aim of this change was to allow more compact XMI
documents to be generated.  [I woould argue this is a bad reason
for this change.  Standard text compression algorithms would give 
ten-fold better compaction than tinkering with XMI encoding.]

Unfortunately, this change has some consequences that were not
apparent at the time:

  1) The rules for encoding values of Attributes got more complex.
     For example, with character and string values, you apparently
     need to see if the value contains 'problem' characters before
     deciding whether to encode them as attributes or elements.

     [It does not help that the XMI 1.1 does not mention this.  It
     doesn't even bother even list the DataTypes that could be 
     encoded as XMI attributes!]

  2) The rules for decoding values are similarly complex.  Indeed
     more so, since the decoder cannot predict what choices the 
     encoder made.

  3) XMI 1.1 value encoding is apparently problematical for XMI
     consumers that are implemented using XSLT.  It has been
     reported that having to look for an Attribute value in
     two places is a serious problem.

     [The counter argument that XMI was not designed to be used
     with XSL is bogus IMO.  We should be supporting a wide spectrum
     of modes of use for XMI.  Besides, the XMI 1.1 spec specificly 
     mentions XSL in 4.3.6 with the implication that it is, or 
     will be supported!]

  4) Having to look in two places will be problematical for conformance
     of hand-built XMI consumers.  A hand built consumer will typically
     be tested against one XMI producer which makes one set of choices
     on encoding Attributes.  If the consumer encounters an XMI document
     generated by different producer software, the chances are that it
     will break.

These problems -- particularly 3) and 4) -- are sufficiently serious
that we should review the decision that XMI 1.1 made to allow simple
DataType values to be expressed in two ways.

Assuming that XMI 1.2 retains XMI 1.1's optional encoding of DataType
values as XML attributes, the specification needs to be fixed as follows:

  *  It should list that DataTypes that can be encoded in two ways, 
     how they are encoded, and the meta-model and runtime contexts under 
     which this is legal.

  *  The spec should say how a decoder should deal with anomalies like
     the following:

       <some.attr xmi.value="1">1</some.attr>
       
       <someother.attr xmi.value="1">2</someother.attr>

       <multi.attr xmi.value="1" />
       <multi.attr>2</multi.attr>

       <string.attr xmi.value="hi">
       </string.attr>

     Which (if any) of the above is legal?

  *  The spec should state explicitly that a decoder that does not
     look in both the xmi.value attribute and the content is not
     XMI 1.2 conformant.  [Not that this helps much in practice :-(]

In trying to implement a consumers for ordered Associations, I've
come across the following anomalies caused by References.

Consider the following metamodel:

package P {
  class C1 {
    reference r1 to a1_e2 of A1;    
  };

  class C2 {
    reference r2 to a2_e1 of A2;
    reference r3 to a1_e1 of A1;
  };

  association A1 {
    end set [0..*] of C1 a1_e1;
    end ordered set [0..*] of C2 a1_e2;
  }

  association A2 {
    end set [0..*] of C1 a2_e1;
    end ordered set [0..*] of C2 a2_e2;
  }

The first anomaly is with the "r2" Reference.  Since this "refers to"
the unordered end of an Association, the "value" of the Reference does
not contain any ordering information.  But, since the Association has a
Reference, the links for the Association won't be output in an
<association-name> element.  In other words, the ordering information
for the Association links will be lost. This is a serious problem. [For
the record, there is nothing "wrong" with the meta-model either IMO]

The second anomaly (or maybe it's just a "feature" ...) is with the
References "r1" and "r3".  The problem is that while the xmi entities
generated for the "r1" Reference can be converted into links, this is
not true for the reverse "r3" References.  Clearly, if I try to use
"add_links" on a C2 instance to set the "r3" Reference values, it is
next to impossible to get the ordering of the A1 links correct. This
makes the "r3" References next to useless ... as well as their being
redundant.

My preferred resolution to this issue would be to simply remove all
handling of References from XMI, and represent all links in the
<association-name> element.

In addition to other anomalies with References, XMI's handling of 
bi-directional References puts redundant information into an XMI
document.  This redundancy adds unnecessary complexity for XMI
document consumers.

Discussion:

For example, consider the following meta-model:

  package P {
    class C1 {
      reference r1 to c2_end of A;
    };
    class C2 {
      reference r2 to c1_end of A;
    };
    association A {
      end set [0..*] of C1 c1_end;
      end set [0..*] of C2 c2_end;
    };
  };

An XMI document will represent a link between a C1 & C2 instance something
like this:

  ...
  <P.C1 id="id1">
    <P1.C1.r1 idref="id2" />
  </P.C1>
  ...
  <P.C2 id="id2">
    <P1.C2.r2 idref="id1" />
  </P.C2>
  ...

It may not be obvious, but when the References are bi-directional (i.e.
on both ends of an Association), one of them is actually redundant.  

So what?

The problem is that this introduces considerable complexity for an
XMI document consumer, especially if the consumer is to protect itself
against erroneous input.

If the consumer assumes that the document is correct, it can statically
choose to use either the "r1" or "r2" information to reconstruct the
links.  [The choice is more complex if the Association is ordered or one
end is not Referenced.]  Note that you can't simply create links for any
References, since that will lead to duplicate links exceptions (or
worse).

The risk with this approach is that the consumer may lose information if
the XMI document doesn't include elements for both References.  For
example, if the input document was produced by hand ...

It is therefore better for the consumer not to assume that the document
is correct.  There are two options:

  1)  Make sure that the "r1" and "r2" information is consistent.  This
      is complex, and probably entails building in-memory copies of
      the links ... which may present scalability problems.

  2)  Create links from the "r1" and "r2" information, catching and
      ignoring any duplicate link exceptions.  This has a couple of 
      problems:

      *  If there are any inconsistencies, they won't be noticed.

      *  It doesn't work for ordered Associations because if you
         add the link corresponding to a Reference that "refers to"
         the unordered end first, you will trash the ordering
         information.

My preferred resolution to this issue would be to drop all XMI handling
of References and represent the links in the <association-name> element.

There are significant inconsistencies in the handling of "classifier-level"
Attributes by the XMI 1.1 spec.

According to the DTD EBNF & pseudo-code, the <content> element should 
contain a <pkg-name> element for the outermost package that contains 
(some of) the classifier-level Attributes as XMI elements and/or XMI 
attributes.  Nested Packages and their classifier-level Attributes
are represented as nested XML elements withing the outer <pkg-name>
element.

By contrast, the document EBNF etcetera do not output a <pkg-name>
element at all. Instead, all classifier-level Attribute values are
output as content elements of the <xmi.content> node.  In fact, the
package nesting structure seems to disappear.  

In practice, the document production rules give a more convenient
XML notation.  It is convenient to have all of the classifier elements
at the beginning of the contents, because they can be easily retrieved
to create the "package instance" that holds the elements described
by the rest of the document.  By contrast, the DTD rules result in
a document in which you have to process the entire document before
you have the classifier-level Attribute values needed to create the
"package instance" object.

It should also be noted that the DTD rules and the document rules are
variously unclear (or say nothing) about the handling of classifier-level
Attributes that belong to super-type Packages and clustered Packages.

My recommended fix would be to standardise on the document rules with
the following change.  The <xmi.content> element should contain a
<pkgname> element for the top-level Package.  This should have xml
elements and attributes for all classifier-level Attributes in Classes
it directly contains or that it inherits.  It should also contain
(recursively) elements for any clustered or nested Packages.

This does four things:

   *  It allows the consumer to tell what kind of Package to generate
      in all situations.

   *  It puts values for all classifier-level Attributes at the front
      of the document.

   *  It means that encoding of classifier-level and instance-level
      Attribute values is uniform.

   *  It avoids the trap of having two or more MOF Attributes in 
      a composed Package map to the same unqualified XML attribute
      name of the top <pkgname> element.  [If it wasn't for this,
      we could collapse all classifier-level Attributes into the
      top level <pkgname> element.]

According to the DTD generation EBNF, a Class element contains embedded
<class-name> elements for Classes (and their subclasses) related as
components via composite Associations.  According to the DTD generation
pseudo-code, the embedded elements are <reference-name> elements.
Neither of these approaches work properly: both fail for some valid and
meaningful meta-models.

Discussion:

The first approach can fail when there is more than one composite Association
in the meta-model.  For example:

  package P {
    class C1 { ... };
    class C2 { ... };
    
    association A1 {
      composite end single C1 the_c1;
      end set [0..*] of C2 the_c2;
    };

    association A2 {
      composite end single C1 the_c1;
      end set [0..*] of C2 the_c2;
    };
  };

The resulting DTD for this meta-model does not allow you to tell if a 
a C1 instance that is related to a (component) C2 instance via an A1
link or an A2 link.

The second approach fails if there is no reference to the component
Class from the composite Class.  For example

  package P {
    class C1 {
      // no reference to the_C2 of A1
    };

    class C2 { ... };
    
    association A1 {
      composite end single C1 the_c1;
      end set [0..*] of C2 the_c2;
    };
  };

Since there is no Reference from C1 to C2, there is no name for the 
element.

I was reading document 00-11-02, i.e. the XMI 1.1 specs, and I was a bit confused with the example of production by Package Extent on page 5-12.

Should the line which says, "Similarly, the second Node in the NodeClass extent..." actually say, "...the second Net in the NetClass extent... "???

There is no reference to PDT, one of the XMI.field values of the second Net object. Also, there seems to be no reference to NodeZ in the same XML, although NodeW is referenced again.

Are these typos??? Sorry for nitpicking :)

n order to exchange UML models by means of XMI, using an external DTD
subset is common to avoid including the DTD into each document. Usage
of SYSTEM identifiers should be avoided, since location of the DTD
might vary between installations.

To detect that a document is based on a well-known DTD (e.g. the XMI
1.1 UML 1.4 DTD), a formal public identifier should be used. Since it
is likely that OMG will need a number of public identifiers, it would
be best if OMG could register an owner ID with ISO. With that, a
DOCTYPE declaration could read

<!DOCTYPE XMI PUBLIC "+//<omg>//DTD UML 1.4 XMI 1.1//EN">

The procedure for registering public identifiers is defined in ISO
9070; registration authority is ANSI (and delegated to
GCA). Alternatively, an owner identifier can be derived through an ISO
6523 organization identifier (authority is BSI), or using the Annex J
IDN scheme.

DTD production rule 6d states that DTD declarations are made for only
non-derived attributes and references.  This is inconsistent with the
document production rules that include derived attributes.

Resolution:
Derived attributes and references in rule 6d are included in DTD
production.

XMI document production rule 7c. states that "The element tag name is the name of the namespace followed by the element name. For class, package and association instances, this name is the name of the type instantiated." It is not totally clear that this permits only the single type that was used to create/instantiate the item, as opposed to another type to which it might conform: in particular the 'target' type of the reference.

The example in section 5.3 still uses the MOF 1.3 DataType system. Specifically DateTimeType should be an instance of StructureType which has StructureFields of 'time' and 'timezone'; and TokenColor as an instance of EnumerationType with labels attribute having values for (at lest) 'blue', 'green' and 'red'. 

The EBNF for attributes does not make clear how the different MOF types are to be represented: it is clear for the PrimitiveTypes (via rule 7i) but not the others. For example, the use of xmi.field for StructureField values is only mentioned as part of the example in section 5. And it's not clear what difference there should be between multivalued attributes and those defined to be a CollectionType. And the nesting of DataTypes should also be addressed (e.g. a StructureField has as its datatype another Structure or CollectionType). Specifically 7h should make it clearer that XML Elements must be used for model attributes with non-Primitive datatype (except if the DataType is an Alias for a PrimitiveType?), as well as for multi-valued attributes. And 8e wrongly states that if not a PrimitiveDataType then "the <AttribContent> is a Class and the <AttribContent> is the Class object". There should be a clear table for all the MOF DataTypes as provided for the PrimitiveTYpes in 7i. 

The example 4 in Appendix A.5 is confusing/misleading and out of scope since the XMI is shown not as generated from an instance of the MOF Model but from an amalgum of UML and IDL metamodels for which no XMI mapping is defined! 

Specifically the way that the Address <<struct>> is represented in both DTD and instances is NOT representative of how MOF StructureType datatypes are to be handled and this could mislead. 

XMI documents for various OMG standards need to be made available 
on the OMG web server in a properly organised directory structure.
The structure need to take account of different versions of the
"domain" standard, different versions of XMI and different versions
of MOF.  It should cater for XMI documents and XMI DTDs, and 
possibly other representations of metamodels, interfaces and so on.

This is of special significance to XMI because the <DOCTYPE> tag of an
XMI document needs to contain a "system id" which is a URN for the
document's DTD.  My understanding is that this URN must be a link to a
publicly accessible copy of the DTD, otherwise the document cannot be
used by typical XMI implementations.

Appendix A of the MOF 1.4 spec (with errata applied) can be viewed as a
first attempt at such a directory structure.  

The section on Linking (3.8 in the XMI 1.2 RTF draft) has a number of
problems.  In general, it doesn't explain the alternative link methods
clearly or give examples for all of them.  It also seems to be offering
lots of alternatives where there is no obvious need to do this.  Some of
the XLink/XPointer formats (e.g. "|descendant(...)" are now apparently
obsolete. Finally, much of the text of 3.8.2.x is ungrammatical and/or
generally hard to read.

The focus is exclusively on generation of XMI Documents and not on their
consumption: how is the consuming program expected to process/interpret
incoming XMI documents. Some specific questions:
 - in what order should the xmi.differences items be applied (compared to
the rest of the document and with each other);
 - how should an incoming document be matched/reconciled with existing
objects (in a repository) e.g. by uuid, xmi.id, some other nominated
property? What impact should the version number of the metadata (as opposed
to the metamodel) have?
 - to what extent should the absence of any links for a
references/composition/association be taken as meaning it should be empty
(and moreover that any existing links of that type for the object concerned
should be deleted)
 - what if hrefs to another document do not uniquely identify an element
(e.g. if xmi.label is used)?
The answers to these questions also have an impact for generators since they
will need to know the impact of various generation choices and be assured of
some consistency. If consuming programs can do what they like with the XMI
file then you lose interoperability.

It should be clarified that hrefs do not have to refer to physical XMI
documents that exist concurrently with the document to hand: the href could
refer to elements in a database or repository so long as, when the first
document is processed, the href can be navigated on demand to produce the
referred-to document or element in XMI form.

The text just says that xmi.import 'identifies additional documents that are
needed to process the current document' but does not say what effect/benefit
the xmi.import has. For example, if one uses xmi.import to reference an
external file, does this make all the elements available in the same xmi.id
address space as the current document (hence it is an error if the imported
document has an xmi.id clash)? The example in A.3 still uses hrefs to refer
to an element (Department.xml#Instructor) in the imported file
Department.xml which implies that the xmi.import is completely redundant
since such an href can be used without the xmi.import being required.
Moreover the usage of the xmi.name and xmi.version attributes are not made
clear: is it a means of selecting a specific model from the referenced file?
(The example does not use version). What is the impact of referencing a
model compared to the other information that may be in the file? Can one
only import a model? Does the xmi.import fail if the file does not contain
the referred-to version of the Model?

Example 3 in A.4 purports to show instances of the Department model defined
in the previous example (it says that "Department is considered the
metamodel for Chemistry"). However Department is not a MOF-compliant
metamodel (it is a fairly basic UML model). So XMI just does not apply!

Similarly the XMI Document Instance in Example 4 in A.5 shows instance data
for the Mail model which again is not a MOF-compliant metamodel.

Several points, the first 3 of which seem to concern the implicit use of a
UML Profile which is not documented, and is not the UML Profile for CORBA
(ad/00-05-07) which one might expect to be used for this:
a) The diagram shows class Address with a stereotype of <<struct>> which is
presumably part of a stereotype uses a UML Profile which is not indicated or
documented in the CCM Spec referred to.
b) Para 2 states that "The Base IDL metamodel should subclass MOF:DataType."
which is not clear (a metamodel cannot be a subclass of a MOF Class). Later
on the statement is made that "Since Address is a definition of a struct, it
is an instance of the IDL metaclass StructDef" without any reasoning. This
would require a mapping between the stereotype in the UML Profile and an IDL
MOF model.
c) It's not clear how the example model would be created: UML requires the
'type' reference of an Attribute to refer to an instance of UML::Classifier.
Does BaseIDL.StructDef inherit from UML::Classifier? With the use of a
profile/stereotype one would end up with an instance of Class with an
attached stereotype of <<struct>>. There's a lot that's not made clear.
d) It would be far more useful to show a UML diagram for StructDef, or even
a fragment of MOF XMI, than a block of DTD which is not adequate as a
_metamodel_ definition - especially in a specification that is supposed to
be describing how to create DTDs _from_ a metamodel.

'<ElementContent>' is used twice in rule 8a in section 6.2, but not defined
anywhere: presumably it should be <ContentElement>.

Adoption of XLink specification (minor)
---------------------------------------------
There are several references (e.g. 3.5.10, XMI.metamodel) to the effect that
"this element is expected to become a simple XLink when the XLinks
specification becomes a recommendation of the W3C ". It has (in June 2001).

Section 3.10 has the following significant issues:
 - it treats xmi.uuids as interchangeable with xmi.externIDs. However the
latter is not defined as globally unique in the same way as uuids;
 - it provides no mechanism to cope with the common case where tools do not
support a globally unique id.
 - it requires that a tool knows whether a uuid was originally generated by
it but provides no mechanism to allow this. For example, in section 3.10.3
step 3, Tool1 needs to be able to recognize that the xmi.uuid "abcdefgh" was
generated by it, yet "X012345678" was not. No information is provided in the
file to allow this and it cannot be assumed that the format of the uuid can
identify the tool that generated it.
 - there are inconsistencies between the text and the XMI. Specifically step
2 should refer to xmi.uuid (instead of xmi.extenderID) of "X012345678" and
step 4 should refer to xmi.uuid (instead of xmi.extenderID) of "qrstuvwxyz"

There are several references (e.g. 3.5.10, XMI.metamodel) to the effect that
"this element is expected to become a simple XLink when the XLinks
specification becomes a recommendation of the W3C ". It has (in June 2001).

It seems for completeness sake, a "XMI.metametametamodel" element would need to be provided to specify the name and version of the metametametamodel (M3 model) being used. This is because XMI doesn't require that the M3 model be MOF. Even if the M3 model must be MOF, then it should still be possible to address which version of MOF is assumed.

Below is an excerpt from the M0-level "Department" model from XMI 1.2, Appendix A.4. I have corrected it (by adding the required "version" attributes and the XML header) and expanded it include a reference to the metametamodel and metametametamodel (using a new "XMI.metametametamodel" element I am proposing):

<?xml version='1.0'?>
<XMI version="1.1" xmlns:Department="edu.university/Department">
  <XMI.header>
    <XMI.model             name="Chemistry"  version="1.0"/>
    <XMI.metamodel         name="Department" version="1.0"/>
    <XMI.metametamodel     name="UML"        version="1.4"/>
    <XMI.metametametamodel name="Model"      version="1.3"/>
  </XMI.header>
  <XMI.content>
    <Department:Department name="Chemistry">
      <Department:Department.instructors>
        <Department:Professor name="Dr. Smith" xmi.id="Smith"/>
        <Department:Postdoc name="Dr. Jones" xmi.id="Jones"/>
        <Department:Lecturer name="Dr. Visitor" xmi.id="Visitor"/>
        <Department:TeachingAssistant name="Fred" xmi.id="Fred"/>
      </Department:Department.instructors>
    </Department:Department>
  </XMI.content>
</XMI>

Basically, the new element would be defined just like {XMI.model}, {XMI.metamodel}, and {XMI.metametamodel}.

OMG received a query last week about XMI, which I answered.  The response
from the originator to my comments about his example were to the effect that
he took them from the XMI spec.  I looked at the XMI spec (Appendix A,
Example 1) and found that the example is not valid UML.

This is the second time that I'm aware of that someone has tried to use this
example in the UML environment and encountered problems, so it clearly needs
to be corrected.

We should aim to fix this at XMI 1.3. I think it belongs in 3.6.1 (para 2)
as well as a (new) section that summarizes all the metamodel tags affecting
XMI. Also I think 3.6.1 is misleading in implying it's up to the DTD
Generator to use whatever namespace it likes and (potentially) ignore what's
specified in the xmi.namespace tag.

Section 3.5.1.2, bottom of p3-7 states "The xmi.id attribute value can be
specified using a special URI form for XPointers defined in the XLink and
XPointer working drafts." It's not clear what this 'special form' is (and in
which working draft) and in any case XLink and XPointer are now
Recommendation and Candidate Recommendation respectively.

Section 3.11 last paragraph refers to "The convention for converting UML
classes to MOF datatypes". This is out of scope for XMI and belongs in UML
Profile for MOF which has now been standardized by OMG (as part of EDOC).

All uses of '|' as separator between URL and XPointer expression should be
replaced by '#'.

Appendix C refers only to the conformance of XMI DTDs and Documents and
provides no statements regarding what it means for a software
implementation/tool to be conformant (except tangentially the first bullets
in C.2.2 and C.2.3 under Usage Compliance). Note that references under Usage
Compliance to early releases of many tools not supporting XML 1.0 are now
outdated and statements about 'conforming to the XML recommendation' are too
vague.

Draft strawman resolution (needs to fully absorb myriad points in issue
3887)
----------------------------
Delete existing sections Usage Compliance under C.2.2 and C.2.3.

Add new section C.3 Software Compliance Points
 -----------------------------------------
 To be "minimally XMI compliant for metamodel M" software must:
  - Produce XMI documents compliant with M (as defined in section C.2.2)
representing its 'internal' elements through the rules of at least one of
Containment or Package Extent.
  - Consume a XMI document compliant with M to create a new set of
'internal' elements.
  - Be at least  'non-validating processor' (as defined in the XML
Recommendation) with respect to a DTD compliant with M (as defined in
section C.2.2).
  - Support at least simple hrefs using xmi.id of the form outlined in
section 3.8.2.1.



 To be "fully XMI compliant for metamodel M" software must:
  - Produce XMI documents compliant with M (as defined in sections C.2.2 and
C.2.3) representing its 'internal' elements through the rules of at least
both of Containment or Package Extent.
  - Consume a XMI document compliant with M to create/update/delete an
existing set of internal elements.
  - Completely process a set of xmi.differences
  - Be a 'validating processor' (as defined in the XML Recommendation) with
respect to a DTD compliant with M (as defined in sections C.2.2 and C.2.3).
  - Support all the href options outlined in section 3.8.2.1.
  - Support tool interchange using the recommendation in section 3.10.
  - Support the exchange of model fragments as described in section 3.7.


 To be "minimally multi-metamodel XMI compliant" software must be minimally
compliant with any metamodel M (as defined above) for any MOF-compliant
metamodel. Additionally it must be able to generate a compliant DTD (as
defined in section C.2.2) for such a metamodel and support at least the XMI
MOF Subset outlined in section C.2.3.

 To be "fully multi-metamodel XMI compliant" software must be fully
compliant with any metamodel M (as defined above) for any MOF-compliant
metamodel. Additionally it must be able to generate a compliant DTD (as
defined in sections C.2.2 and C.2.3) for such a metamodel

On page 394 (/400) of your whitepaper on XMI, version 1.1, you have falsely stated that "UML, the" is an "acronym: The Universal Modeling Language". It is in fact an acronym for the UNIFIED Modeling Language. 

xmi.exporterId inconsistently used and undefined
Section 3.5.8 includes an element declaration for xmi.exporterId. However it
is not included as a valid member of XMI.Documentation (the subject of the
section) either in 3.5.8 or 4.4, nor the description at the start of 3.5.8.
Although it is in production rule 3a.
(Nor incidentally is it mentioned at all in the XMI Production of XML
Schemas spec)

Proposed Resolution
Since there appears to be no use for xmi.exporterId delete it from 3.5.2,
3.5.8, 4.4 and production rule 3a.

What is the intended purpose of the "xmi.label" attribute? The XMI
specs. don't seem to give it any semantics. They just say that the user
may put any value in the attribute.

If my XMI processor that imports an XMI document and then serializes it
back out with all the "xmi.label" attributes removed or perhaps randomly
modified, would my processor be breaking any XMI conformance rules?

In keeping with the new MOF 1.4 specification, XMI 1.2 has removed all
references to the "old" MOF type mechanism based on CORBA IDL types. A
wonderful simplification of both MOF and XMI - no complaints!

However, the new simplified MOF type concept has not been included.
Specifically: there are no explicitly stated rules for encoding
StructureType, AliasType or CollectionType.

Probably linked to this is the fact that the pre-defined XMI elements
XMI.field, XMI.sequence and XMI.seqItem are stated to be "...used only when
required by the metamodel" [XMI 1.2, pp. 4-17]. And since they are never
referenced by the rest of the specification, this apparently means "never".

It is of course not difficult to connect these two peculiarities and deduce
how the new MOF datatypes should be encoded, but it should really be stated
explicitly.

Reading through the XMI 1.2 spec, I notice that a peculiar DTD production is
still there: the <9:PackageElementDef> on page 4-10.

In short, this means that if I have say a very simplified UML metamodel,
containing only the "Core" package, containing the single empty class
"ModelElement", I will get the following DTD (fixed elements omitted):

<!ELEMENT Uml:Core (Uml:ModelElement)*>
<!ATTLIST Uml:Core
	%XMI.element.att;
	%XMI.link.att;
>
<!ELEMENT Uml:ModelElement EMPTY>
<!ATTLIST Uml:ModelElement
	%XMI.element.att;
	%XMI.link.att;
>

My problem here is this: why would you ever want to use the Uml:Core package
element? Since packages cannot be instantiated, there will never be a
package instance to serialize..

And, interestingly enough, the XML document production part of the
specification never uses the package element either.

The XMI 1.2 spec - like its predecessor - extols the virtues of the "General
Datatype mechanism" [XMI 1.2, pp. 3-30], showing e few examples of how
useful it is.

Maybe it's just me missing the point here: but what IS this mechanism, and
where is it defined?

I have read the examples given on page 3-30 about 20 times, but I still
don't understand what is going on.

In any metamodel it is possible to specify an xmi namespace for a package using xmi.namespace tag, however the tag value seems to contain only the name of the namespace. How is the XMI writer supposed to know the URI of the namespace to be able to generate the namespace declaration into the XMI file?

Concrete example:
MOF has an xmi.namespace=Model tag attached to the Model package.
Now suppose I have a MOF metamodel and want to serialize it into the XMI. The XMI writer needs to declare Model namespace like this:
<XMI  xmlns:Model="org.omg.mof.Model">
Where is the XMI writer suppose to get the "org.omg.mof.Model" thing to generate it into the XMI? It is not explicitly specified anywhere in the MOF 1.4 model. Or can I generate just any URI I like? :)

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

If we haven't already I think we need to propose a new tag to be applied to
metamodels which will contain the URI for the namespace (as opposed to the
namespace name which is given by the existing tag xmi.namespace).
e.g. xmi.namespaceURI

Two main reasons for doing this:
 a) automated generation of the DTD/schema for standards
 b) (and more importantly) allow instance documents to be generated with the
right URI (which is obviously important) - without implementations having to
hardcode a value or guess (which is what they have to do currently).

I have noticed that UML 1.4 metamodel heavily uses tag named
org.omg.xmi.enumerationUnprefix. The UML 1.4 metamodel that is on the OMG
server is in form of XMI 1.1. I could not find description of this tag in
XMI 1.1 spec. Is this tag described somewhere? Why is it used? IMHO it only
complicates the implementation of XMI readers/writers without any
significant reason.

It's possible to create a composition without having a Reference from the
composite to the component. This is not obscure - a prime example of this is
in UML: a ModelElement owns Tags but has no reference to them.
The XMI production rules talk only about traversing composite *references*.


Production by object containment is described as follows (section 5.3.1 of
XMI 1.2 formal spec):
"...XMI provides for XML document production by object containment. Given a
composite object, XMI’s rules define the XML document, which represents the
composite object and all the contained objects in the composition hierarchy
of which it is the root."
However the detailed rules will not achieve this if there is not a reference
from composite to component.


It gets worse - moving onto Production by Package Extension, the text in
5.3.3 (bottom of p5-9) states:
"Then, the SimplePackageClass is traversed. For each RefObject instance, the
extent is examined. Any object that is not participating as a component in a
composition link becomes the starting point for generating XML."


Because the components we're talking about DO participate as a component in
a composition link then these components will neither be starting points for
generating XML nor exported as part of their composition (since they are not
referred to by a reference).

Proposed Resolution
-------------------


1. Change the text in 5.3.1 (page 5-3) from:
"The MOF supports the use of References in defining metamodels. A reference
provides
the object’s navigability to linked objects. Following the attributes of an
object, each of
its references are written. XMI considers references to be of two different
types and
treats them differently.
An object linked to another via a link defined in the metamodel as having an
aggregation other than composite is considered to be a normal reference. On
the other
hand, if an object is linked to another object via a link defined in the
metamodel as a
composite association, with the composite end corresponding to link end of
the
composite object, then the reference used is a composite reference."
To:
"The MOF supports the use of References in defining metamodels. A reference
provides
the object’s navigability to linked objects. Following the attributes of an
object, each of
its references are written. In addition contained objects that are navigable
via a reference are written 'outside' the composite object.
XMI considers references to be of two different types and treats them
differently.
An object linked to another via a link defined in the metamodel as having an
aggregation other than composite is considered to be a normal link, and the
coresponding references considered normal references. On the other hand, if
an object is linked to another object via a link defined in the metamodel as
a
composite association, with the composite end corresponding to link end of
the
composite object, then the link is considered to be a composite link. If
navigable via a reference this is considered a composite reference."


2. Add the following to the end of section 5.4.3 (Links not represented by
references)
"A special case for Production by Object Containment is where the composite
link does not have a composite reference: in this case the elements for the
component objects will not be nested within that for the composition so are
written out separately. If the component has a reference back to the
composite then this is sufficient and a separate element is not needed to
the association. The production rules are then applied as normal to these
composite objects (e.g. they may have their own nested elements)."


3. Change the text in 5.3.3 (bottom of p5-9) from:
"Then, the SimplePackageClass is traversed. For each RefObject instance, the
extent is examined. Any object that is not participating as a component in a
composition link becomes the starting point for generating XML."
to:
"Then, the SimplePackageClass is traversed. For each RefObject instance, the
extent is examined. Any object that is not referred to via a reference from
the composite in a composition link becomes the starting point for
generating XML."


4. Change the description of production rule 6a in 6.2 (p6-5) from:
"The contents are a set of top level objects, classifier level attributes,
and other
links."
To:
"The contents are a set of top level objects, classifier level attributes,
and other
links. The top level objects will include those which have a composite link
with no reference from the composite to component."


5. Change the description of production rule 8 in 6.2 (p6-8) from:
"The contents of an object is a (possibly-empty) sequence of
<ContentElement>s,
one or more per instance-level attribute or reference (composite or
non-composite)
of the object."
To:
"The contents of an object is a (possibly-empty) sequence of
<ContentElement>s,
one or more per instance-level attribute or reference (composite or
non-composite)
of the object. Note that 'contents' (component objects which are reached via
composite links) without a composite reference are not subject to this
production rule and so not written as nested elements: instead they are
written as top-level elements."

There are several problems related to the specification of Association
elements (representing Links).


1) At the moment Association elements are only generated in DTDs/Schemas for
referenceless associations.
This precludes the use of Association instances in XMI files to link
existing/external objects: a technique I have certainly found useful even
when those objects do have references. There seems to be little reason for
not generating the Association elements.


2) The description of DTD design principles in 3.6.6 refers to association
roles. Presuming this is intended to mean association ends, the text is not
accurate since the element name generated is based on the reference name for
the class which may differ from the association end name.


3) Section 3.6 does not mention the creation of Association elements even
for the existing referenceless Association case.


4) The DTD and document generation rules for Association elements are
unnecessarily heavyweight and inconsistent with the treatment of references
on classes. For example it does not make sense for an AssociationEnd element
to have the fixed xmi attributes; and it should be possible to dispense with
them completely: letting an Association element refer to the linked elements
using XML attributes. e.g. for association A with ends b and c, a link could
be represented as follows (b1 and c1 are xmi.id's):  <A b=b1 c=c1 />).

Proposed resolution


A) In 3.6.6 replace:
"Each association role is represented in an XML entity, an XML element, and
an XML
attribute. The multiplicity of the role is not used to create the
declarations in XMI 1.2.
The representation of an association role named “r” for a metamodel class
 “c” is:
<!ELEMENT r ( content)* >
"
By:
"Each reference is represented in an XML entity, an XML element, and an XML
attribute. The multiplicity of the association end is not used to create the
declarations in XMI 1.2.
The representation of a reference named “r” for a metamodel class “c” is:
<!ELEMENT r ( content)* >"


B) Add the following to the end of 3.6.6
"Each association and association end is also represented by an XML element.
This is essential for associations where both association ends have no
corresponding reference in the linked class, but can also be useful for
linking objects even when references are present.
The declaration uses the same style for the association ends within the
association as for references within a class.
The following is the representation of metamodel association named "A"
linking classes "B" and "C" via association ends "b" and "c". (This assumes
that B and C have no subclasses).
<!ELEMENT A.b (B)? >
<!ELEMENT A.c (C)? >
<!ELEMENT A (A.b | A.c)* >
<!ATTLIST A
   b IDREFS #IMPLIED
   c IDREFS #IMPLIED
   %XMI.element.att;
   %XMI.link.att;
>


C) In 4.3.1.9 add to the end of description of DTD production rule 9f:
However it is also useful to be able to instantiate Associations by
specifying links, even when they do have references, so at all Associations
in the Package will be listed.


D) In 4.3.1.10 change the description of DTD production rule 10 from:
"The XML elements for unreferenced Associations consist of definitions for
its AssociationEnds and for the Association itself."
to:
"The XML elements for Associations consist of definitions for its
AssociationEnds and for the Association itself."


E) In 4.3.1.11 Replace the rule set:
11. <AssociationEndDef> ::= "<!ELEMENT" <11a:AssocEndElmtName> "EMPTY" ">"
"<!ATTLIST" <11a:AssocEndElmtName>
<11c:AssocEndAtts> ">"
11a.<AssocEndElmtName> ::= <12a:AssnElmtName> "." <11b:AssocEndName>
11b.<AssocEndName> ::= //Name of AssociationEnd//
11c.<AssocEndAtts> ::= <1a:XMIFixedAttribs>"
Description:
11. The declaration for an AssociationEnd XML element has no content model,
though it has the standard set of XML attributes.
11a.11b. The name of the AssociationEnd XML element is the element name of
the association containing the AssociationEnd, a dot separator, and the name
of the AssociationEnd.
11c. The fixed identity and linking XML attributes are the AssociationEnd’s
only XML attributes.


by the following:
11. <AssociationEndDef> ::= "<!ELEMENT" <11a:AssocEndElmtName>
<11c:AssocEndContents> ">"
11a. <AssocEndElmtName> ::= <12a:AssnElmtName> "." <11b:AssocEndName>
11b. <AssocEndName> ::= //Name of Association End//
11c. <AssocEndContents> ::= "(" <6a:ClassElmtName>
( "|" <6a:ClassElmtName> )* ")?"
Description:
11. The declaration of an AssociationEnd element within an Association is
the same as that for a ReferenceElement within a Class (see Rule Set 5): the
only exception is in Rule 11c. where at most one class instance may be
referred to by each link.


F) In 4.3.1.12 change the description of DTD Rule 12d from:
12d.<AssnAtts> ::= <1a:XMIFixedAttribs>
to
12d.<AssnAtts> ::= <6i:ClassAttribRef> <6i:ClassAttribRef>
<1a:XMIFixedAttribs>


Change the descriptions for RuleSet 12 from:
12, 12c. The declaration of an unreferenced Association consists of the
names of its AssociationEnd XML elements.
12a. 12b. The name of the XML element representing the Association.
12d.The fixed identity and linking XML attributes are the Association XML
attributes.


to:
12, 12c. The declaration of an Association consists of the names of its
AssociationEnd XML elements.
12a. 12b. The name of the XML element representing the Association.
12d. As for references from classes, XML attributes may be used instead of
AssociationEnd elements: in this case one for each association end. The
fixed identity and linking XML attributes are also Association XML
attributes.



G) In 6.2 change XMI document production rule 10 from:
10. <OtherLinks> ::= <10a:AssociationStart>
( <10c:AssociationEndRef> <10c:AssociationEndRef> )*
<10b:AssociationEnd>
10a.<AssociationStart> ::= <7a:ObjectStart>
10b.<AssociationEnd> ::= <7b:ElementEnd>
10c.<AssociationEndRef> ::= <7a:ObjectStart> <7g:ObjectRef> <7b:ElementEnd>
Description:
10. All associations that have no references are placed here. Each
associationEnd’s links are contained as pairs of nested XML elements.
10a. The start tag of the association begins with the association name.
10b. The end tag of the association element.
10c. A reference to the linked element from the AssociationEnd.


to:
10. <OtherLinks> ::= <10a:AssociationStart> (<10d:AssociationContents>) |
( <10c:AssociationEndRef> <10c:AssociationEndRef> )*
<10b:AssociationEnd>
10a.<AssociationStart> ::= <7a:ObjectStart>
10b.<AssociationEnd> ::= <7b:ElementEnd>
10c.<AssociationEndRef> ::= <7a:ObjectStart> <7g:ObjectRef> <7b:ElementEnd>
10d.<AssociationContents> ::= <AssocEndValueAtt> <AssocEndValueAtt>
10e.<AssocEndValueAtt> ::= <10g:AssocEndName> "=" <10f:AssocEndValue>
10f.<AssocEndValue> ::= //reference id//
10g.<AssocEndName> ::= //Name of defining association end//
Description:
10. All associations that have no references are placed here. For import any
associations may be placed here. Each associationEnd’s links are contained
as pairs of nested XML elements. As an alternative XML attributes may be
used to refer to the linked elements as for references on class elements.
10a. The start tag of the association begins with the association name.
10b. The end tag of the association element.
10c. A reference to the linked element from the AssociationEnd.
10d. As an alternative to nested AssociationEndRef elements a pair of XML
attributes may be used to reference the two objects linked.
10e. The name of the association end is used in the same way as a reference
name in a class, except that only a single value is permitted.

1) In "3.6.1 Namespace Qualified XML Element Names" on site 3.15. An example
uses inheritance, what is explained later, we should find another example.

2) In "3.6.4 Inheritance Specification" on site 3.17. What makes '%' in
first line of element declaration?:
<!ELEMENT % C1 (C0.a0 | C1.a1 | XMI.extension | C0.r0 | C1.r1 | C0.comp0 |
C1.comp1)* >

3) In "3.6.5 Attribute Specification" on site 3.17.
There is:
<!ELEMENT a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED >


Should be:
<!ELEMENT c.a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED >


The same error repeated on next site, where should be:
<!ELEMENT c.a1 (#PCDATA | XMI.reference) *>
<!ELEMENT c.a2 EMPTY >
<!ATTLIST c.a2 xmi.value (true | false) #REQUIRED >


The same error repeated on bottom direct before note, where should be:
<!ELEMENT c.a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | .) #REQUIRED d >

4) "3.6.4 Inheritance Specification" should go after "3.6.5 Attribute
Specification" because uses attribute concepts explained in 3.6.5.

General question to "3.6.4 Inheritance Specification": Why we declare all
XML elements and XML attributes direct under class C0 declaration and not as
parameter entity named like:


<!ENTITY % C0.elem "C0.a0">
<!ENTITY % C0.ref  "C0.r0">
<!ENTITY % C0.comp "C0.comp0">


<!ENTITY % "C0.attr
a0 CDATA #IMPLIED
a1 CDATA #IMPLIED
r0 CDATA #IMPLIED
r1 CDATA #IMPLIED
>


and then:
<!ELEMENT C0 (%C0.elem; | XMI.extension | %C0.ref; | %C0.comp;)*>
<!ATTLIST C0
        %C0.attr;
        %XMI.element.att;
        %XMI.link.att;"
>


and for third subclass analogical:


<!ELEMENT C3
        (%C0.elem; | %C1.elem; | %C2.elem | %C3.elem | XMI.extension |
        %C0.ref; | %C1.ref; | %C2.ref; | %C3.ref |
        %C0.comp | %C1.comp | %C2.comp | %C3.comp )*>


* >
<!ATTLIST C3
        %C0.attr;
        %C1.attr;
        %C2.attr;
        %C3.attr;
        %XMI.element.att;
        %XMI.link.att;"
>


Imagine how short would be the DTD of UML in such an format.



It can be even shorter if we declare only one entity for all subelements
like:


<!ENTITY % C0.elem "C0.a0 | C0.r0 | C0.comp0 | XMI.extension">
<!ENTITY % C1.elem "%C0.elem | ... my own elements without XMI.extension ...
">


and than any n-subclass:


<!ENTITY Cn "%C'n-1'.elem | ... my own elements without XMI.extension ...">
<!ELEMENT Cn (%Cn.elem;)*>


analogical implified form for ATTLIST is applicable, the last example could
be:


<!ENTITY Cn.attr "
        %C'n-1'.attr
        ... my own elements without %XMI.element.att; and %XMI.link.att; ... ">
<!ATTLIST Cn
        %Cn.attr;
>

The example model encoding XML is invalid, according to the DTD that appears above it. It shows <Envelope.toAddress> and <Envelope.fromAddress> tags which are not as described in the DTD, instead of containing nested <Address> tags, as it should. 

I found this confusing and in fact implemented code that handled parsing of erroneous constructs such as these because I thought I had misread the specification portions of the document. The error has been present since early versions of the XMI 1.1 specification. 

The DTD's (01-04-03) for XMI 1.2 does not correspond to the specification of the xmi.version attribute (section 3.5.3). This makes it difficult to detect whether XMI 1.1 or 1.2 was used to export a UML model. 

This is a feature request for the XMI 2.1 RTF. (Does
it have a mailing list? I'm crossposting to the XML
Schema FTF in case that list is still alive.)


My base document is the proposed available specification
(ptc/02-06-03). (I did not find a later version.)


Section 2.10.2, "Linking" specifies that "the URI
reference must be of the form URI#id_value, where URI
locates the XML file containing the XML element to link
to, and id_value is the value of the XML element's XMI
id attribute."


I propose to add the feature that if the URI does not
contain a fragment, then the link is to the outermost
document element of the referenced file.


This is a common use case, and allows linking to a
document that was provided by someone else and not
annotated with values for the optional xmi:id attribute.


Therefore I propose to change the text in 2.10.2.1 (the
"Using the XMI href attribute to locate an XMI id" sub-
section):


 The URI reference must be of the form URI#id_value,
 where URI locates the XML file containing the XML
 element to link to, and id_value is the value of
 the XML element's XMI id attribute.


to


 If the URI reference contains a fragment identifier
 (as in URI#id_value), then the URI locates an XML
 file, and the fragment identifier is used to locate
 an XML element with the fragment identifier as its
 XMI id attribute. If the URI reference does not
 contain a fragment identifier, then the outermost
 document element of the XML file is referenced.


And to change, in 2.10.2.2 (the "Using an XLink simple
link and XPointer bare name to locate an XMI id" sub-
section) likewise:


 The value of xlink:href must again be a URI reference
 of the form URI#id_value. In this case, id_value is
 technically an XPointer bare name, but it looks just
 like the id_value for the XMI href attribute.


to


 The value of xlink:href must again be a URI reference,
 which is evaluated as above. If the URI reference
 contains a fragment identifier, which is then
 technically an XPointer bare name, then the fragment
 identifier is used to locate an XML element with the
 fragment identifier as its XMI id attribute in the
 referenced XML file. If the URI reference does not
 contain a fragment identifier, then the outermost
 document element of the XML file is referenced.

This is an urgent XMI 2.0 issue. All section and page numbers are against XMI 2.0 (formal/03-05-02).


Section 1.11 (page 1-26) introduces the org.omg.xmi.attribute and org.omg.xmi.element tags to drive schema and document production so that a MOF attribute becomes either an XML attribute or subelement (or both, if both tags are false).


Chapter 3 (XML Document Production) explicitly evaluates these tags, in rule 3g (page 3-6) or rule 5 (page 3-9).


However, chapter 2 (XML Schema Production) does not mention these tags at all, so they are ignored by the schema production rules. Therefore, an XML Schema that is produced using these rules always contains attribute and element definitions for each MOF attribute.


To avoid this ambiguity, rules 4i and 4j should only be executed if org.omg.xmi.element is false. Rules 4d and 4e should only be executed if org.omg.xmi.attribute is false.