Issues for mof2xmi list

To comment on any of these issues, send email to mof2xmi-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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

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

Issue 6345: XMI for TypeLibrary::Objects::Object is Unspecified
Issue 6394: XMI for MOF 2 defines tagged values
Issue 6635: ISSUE: XMI for MOF 2 should address models, not just metamodels
Issue 6636: ISSUE: XMI for MOF 2 does not reflect MOF 2 model
Issue 7306: Mandatory Extensions when enforceMinimumMultiplicity is true
Issue 7381: section 7.10.2.2(.2) on page 23 (editorial)
Issue 7382: section 8.2.1 on page 46 (editorial)
Issue 7383: section 8.2.1 on page 44 (editorial)
Issue 7384: section 8.2.1 on page 46 (editorial)
Issue 7648: XMI 2.0 terminology
Issue 8669: Revise 7.13.2 XMI Document Exchange with Multiple Tools

Issue 6345: XMI for TypeLibrary::Objects::Object is Unspecified (mof2xmi-ftf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
Issue for XMI for MOF 2


The specification of XMI for MOF 2 does not describe handling of MOF's
object type, which is a supertype of ordinary class types as well as data
types.  Particularly, it does not describe what XML results from the
following small example.  The whole model is this:


In a package M there is one class X having one owned attribute named Y of
type TypeLibrary::Objects::Object with multiplicity 1..1.


Consider the following 4 instances of X:


1. An instance of X having Y set to the second instance of X.
2. An instance of X having Y set to the integer 3.
3. An instance of X having Y set to the string "this UNICODE string".
4. An instance of X having Y set to that same fourth instance of X.


What would an XMI-based serialization of these four instances of X look
like?


What would an XML schema for the package M look like?

Resolution:
Revised Text:
Actions taken:
September 4, 2003: received issue

Issue 6394: XMI for MOF 2 defines tagged values (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
The XMI for MOF 2 specification defines several tagged values for adding
data to a UML model that guide generation of an XML Schema and that guide
document production.  But these tags appear to be defined as if for MOF 1.
To be appropriate for MOF 2 these must be defined using either an extension
to the MOF or UML core models (as a package that adds to MOF and/or UML
infrastructure) or they must be defined as a UML 2 profile.  In either case,
an official XML rendering of the model or profile is required.  And given
the big change from MOF 1, an example of such tags as they would appear in
an XMI-based XML document of an example model would be very helpful.

Resolution:
Revised Text:
Actions taken:
October 30, 2003: received issue

Issue 6635: ISSUE: XMI for MOF 2 should address models, not just metamodels (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
The XMI for MOF 2 specification has not been updated to reflect one of the key goals in the alignment of MOF 2 with UML 2, which is that XMI becomes applicable to UML class models in general rather than to MOF-based metamodels only.


Recommended Resolution:  Replace "metamodel" with "model" in most places within the XMI for MOF 2 specification.  Also, in describing the mapping from classes, properties, etc. to XML, do not use wording that implies a restriction to a MOF context except where MOF is , such as for elements of the MOF Type Library.

Resolution:
Revised Text:
Actions taken:
November 20, 2003: received issue

Issue 6636: ISSUE: XMI for MOF 2 does not reflect MOF 2 model (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:
The XMI for MOF 2 Specification seems to have been written as if referring to a MOF 1 Specification.  For example, it defines mappings and mapping parameters for AssociationEnd, which is not in MOF 2.


Recommended Resolution:  Restate the XMI rules and mapping parameters in terms of MOF 2 and UML 2.

Resolution:
Revised Text:
Actions taken:
November 20, 2003: received issue

Issue 7306: Mandatory Extensions when enforceMinimumMultiplicity is true (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
My base document is the MOF 2 XMI Final Adopted Specification,
ptc/03-11-04.


There is an issue with rule 4c, part of the XML Schema Production rules,
on page 46.


If either org.omg.xmi.enforceMinimumMultiplicity or org.omg.xmi.enforce-
MaximumMultiplicity is true, then rule 4 places the 4b:ClassContents in
an xsd:sequence element -- and subelements are then decorated with
minOccurs and maxOccurs attributes.


However, rule 4c still emits the constant element,
<xsd:element ref='xmi:extension'/>


Therefore, in this case, the extension element becomes mandatory, with
an implicit multiplicity of 1..1. This needs to be changed to
<xsd:element ref='xmi:extension' minOccurs='0' maxOccurs='unbounded'/>

Resolution:
Revised Text:
Actions taken:
May 6, 2004: received issue

Issue 7381: section 7.10.2.2(.2) on page 23 (editorial) (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
I've posted these to the XMI 2.1 RTF before. Since these typos still
exist in the MOF2XMI Final Adopted Spec (ptc/03-11-04), I figured I
should send them again. As editorial issues, they were not assigned
an official issue number.


In section 7.10.2.2(.2) on page 23, the URN for the XMI namespace
needs to be in lowercase, according to W3C. Thus, change


  xmlns:xlink="http://www.w3.org/1999/XLink"


to


  xmlns:xlink="http://www.w3.org/1999/xlink"


Resolution:
Revised Text:
Actions taken:
May 19, 2004: received issue

Issue 7382: section 8.2.1 on page 46 (editorial) (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
In section 8.2.1 on page 46, change the first three lines of rule
4. ClassTypeDef from (Note mis-placed closing quote for "name"
attribute)


  "<xsd:complexType name='" //Name of Class//
      ("mixed='true'")?
  "'>"


to


  "<xsd:complexType name='" //Name of Class// "'"
      ("mixed='true'")?
  ">"

Resolution:
Revised Text:
Actions taken:
May 19, 2004: received issue

Issue 7383: section 8.2.1 on page 44 (editorial) (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
In section 8.2.1 on page 44, change rule 1g. XMIFixedAttribs from
(missing end of tags on line 2 and 4, missing namespace tag on line 3)


  ( "<xsd:attribute ref='xmi:id'"
        "use='optional'>" |
    "<attribute name='" //Id attrib name// "'"
        "type='xsd:ID' use='optional'" )
  "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"


to


  ( "<xsd:attribute ref='xmi:id'"
        "use='optional'/>" |
    "<xsd:attribute name='" //Id attrib name// "'"
        "type='xsd:ID' use='optional'/>" )
  "<xsd:attributeGroup ref='xmi:ObjectAttribs'/>"

Resolution:
Revised Text:
Actions taken:
May 19, 2004: received issue

Issue 7384: section 8.2.1 on page 46 (editorial) (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
In section 8.2.1 on page 46, change the fourth and fifth line of
rule 4. ClassTypeDef from (missing eod of tag '>')


  ( "<xsd:complexContent>"
    "<xsd:extension base='" 4a:ClassTypeName "'")?


to


  ( "<xsd:complexContent>"
    "<xsd:extension base='" 4a:ClassTypeName "'>")?

Resolution:
Revised Text:
Actions taken:
May 19, 2004: received issue

Issue 7648: XMI 2.0 terminology (mof2xmi-ftf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
I am reading through the XMI 2.0 "convenience document" ptc/04-06-11 and
I am getting stuck trying to figure out the terminlogy. In particular,
what precicely is a "reference," what is an "association end," and what
is an "association role?" "Reference" and "association end" seem to be
leftovers from MOF 1.4, while "association role" is maybe a leftover
from UML 1.x. But, as far as I can tell these constructs do not exist
any more in MOF 2, so some definitions for them are need. Are these
suitable definitions?:


Reference: A reference is a Property owned by a Class (ownedProperty)
with isComposite=false and a type that is a subtype of Class.
Association End: An association end is a Property owned by an
Association (ownedEnd).
Association Role: An association role is an association end.


In section 7.8.4, there is a statement "For multi-valued Properties, no
XML attributes are declared; each value is encoded as an XML element."
However, the OMG-provided XMI 2.0 representations of the EMOF/CMOF
models use attributes to represent multi-valued Properties that meet the
definition of "Reference" above. This seems to be a contradiction. I
assume that the XMI spec should say "For multi-valued Properties, no XML
attributes are declared; each value is encoded as an XML element, unless
the Property is a Reference."


Resolution:
Revised Text:
Actions taken:
August 13, 2004: received sisue

Issue 8669: Revise 7.13.2 XMI Document Exchange with Multiple Tools (mof2xmi-ftf)

Click
here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:
This applies to XMI 2.1 - ptc/04-06-11.


The above section proposes a scheme that does not hold water. In particular it does not provide a means for the original tool to recognize its own objects. For this a simple extension is neded that assigns extenderIds at the same time as uuids. In addition it is also important that the exporterId is set.



Proposed resolution: see ad/2005-03-06 for a change-barred proposed text.

Resolution:
Revised Text:
Actions taken:
March 31, 2005: received issue