${taskforce.name} Avatar
  1. OMG Task Force

XMI 1.3 RTF — Closed Issues

  • Key: XMI13
  • Issues Count: 19
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
XMI13-21 XMI Schema FTF issue - referenceless composition does not export components XMI 1.2 XMI 1.3 Resolved closed
XMI13-20 Default Value of contentType Tag Should Be Nil XMI 1.2 XMI 1.3 Resolved closed
XMI13-19 Type Declaration Unnecessarily Duplicated XMI 1.2 XMI 1.3 Resolved closed
XMI13-22 XMI Schema FTF issue - Major changes in SOAP encoding rules XMI 1.2 XMI 1.3 Resolved closed
XMI13-18 Full compliance with XLink XMI 1.2 XMI 1.3 Resolved closed
XMI13-14 Use separate attribute for XMI vs data 'version' XMI 1.2 XMI 1.3 Resolved closed
XMI13-16 Section 9.2.1 of the XMI production of XML Schema XMI 1.2 XMI 1.3 Resolved closed
XMI13-17 Unclear software compliance XMI 1.2 XMI 1.3 Resolved closed
XMI13-15 Wrong cardinality in Schema for Difference.container reference XMI 1.2 XMI 1.3 Resolved closed
XMI13-10 Describe Tags further XMI 1.2 XMI 1.3 Resolved closed
XMI13-12 Level of required support for XPointer XMI 1.2 XMI 1.3 Resolved closed
XMI13-11 Clarify Management of Tags in MOF Models XMI 1.2 XMI 1.3 Resolved closed
XMI13-13 Namespace logical identifiers should include version XMI 1.2 XMI 1.3 Resolved closed
XMI13-9 Clearer support for data as well as metadata XMI 1.2 XMI 1.3 Resolved closed
XMI13-8 Generating both Attributes and Elements for MOF attributes/references XMI 1.2 XMI 1.3 Resolved closed
XMI13-7 Combined document structure unclear XMI 1.2 XMI 1.3 Resolved closed
XMI13-6 Keeping pace with XMI 1.x and MOF 1.x XMI 1.2 XMI 1.3 Resolved closed
XMI13-5 Update Section 9.3.1 to reference Chapter 4 XMI 1.2 XMI 1.3 Resolved closed
XMI13-4 Aggregations are Undifferentiated XMI 1.2 XMI 1.3 Resolved closed

Issues Descriptions

XMI Schema FTF issue - referenceless composition does not export components

  • Key: XMI13-21
  • Legacy Issue Number: 5321
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This I think brings the spec into line with what implementations do in
    practice!

    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.

    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 description of production rule 2a in 6.3.2 (p6-101) from:
    "The content elements are the XML representations of top level objects,
    classifier level attributes, and other links."
    To:
    "The contents are the XML representations 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."

    2. Add a new sentence after the first to rule 5 in 6.3.2 (p6-107) changing
    the start of the rule from:
    "The contents of an object are the attributes, references, and compositions
    that are serialized as XML elements, as well as the extensions."
    To:
    "The contents of an object are the attributes, references, and compositions
    that are serialized as XML elements, as well as the extensions. 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."

  • Reported: XMI 1.2 — Wed, 22 May 2002 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see below

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Default Value of contentType Tag Should Be Nil

  • Key: XMI13-20
  • Legacy Issue Number: 5233
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    Currently, the XML schema generation rules for references and compositions
    indicate that the elements corresponding to these MOF constructs can have
    any content and any attributes, unless the useSchemaExtensions tag is true,
    or the contentType tag is complex.

    The default value of the contentType tag is complex. This means that
    elements corresponding to references and compositions are set to the schema
    type corresponding to the MOF class that is their type in default XMI 2.0
    schemas.

    For example, if there is a MOF model with a class Container that is related
    via a composition relationship to a class called Part, and the Container
    class has a reference called part, the relevant part of the Container type
    is the following by default:

    <xsd:complexType name="Container">
    ...
    <element name="part" type="Part"/>
    ...
    </xsd:complexType>

    If the class Part has subclasses, Part1 and Part2, each of which has local
    attributes and references, the default declaration of Container is as
    above. Also, the types in a schema corresponding to Part1 and Part2 are not
    related by schema extension, since the default value of useSchemaExtensions
    is false.

    However, documents in which Part1 or Part2 are serialized in the "part"
    element (and values of the local attributes and references are serialized
    for them), do not validate with the default schema, because they are not of
    type "Part". I believe that default XMI 2.0 schemas should validate
    documents with either Part, Part1, or Part2 serialized in the "part"
    element.

    To avoid this problem, I propose that the default value of the contentType
    tag be no value (nil), rather than complex.

    I believe we intended that the type of elements such as "part" would allow
    any content in default XMI 2.0 schemas, and if someone knows about XML
    schemas, that person can use the XMI tags to create schemas that are more
    restrictive than the default schemas.

  • Reported: XMI 1.2 — Fri, 26 Apr 2002 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Type Declaration Unnecessarily Duplicated

  • Key: XMI13-19
  • Legacy Issue Number: 5090
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    n the XMI 2.0 specification, the default schema production rules require
    each reference to include an anonymous type:

    <xsd:complexType>
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
    <xsd:any processContents="skip"/>
    </xsd:choice>
    <xsd:anyAttribute processContents="skip"/>
    </xsd:complexType>

    This results in large schemas and does not take advantage of the ability to
    reuse types. Why not put a type in the fixed declarations schema and reuse
    it instead?

  • Reported: XMI 1.2 — Mon, 25 Mar 2002 05:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    Add a type called Any to the XMI namespace

  • Updated: Sat, 7 Mar 2015 04:37 GMT

XMI Schema FTF issue - Major changes in SOAP encoding rules

  • Key: XMI13-22
  • Legacy Issue Number: 5325
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    The W3C XML Protocol Working Group has made available a SOAP
    Version 1.2 Part 2: Adjuncts Editors' Copy dated May 14 2002. In this new
    version of the spec, the section describing the SOAP encoding rules has
    changed dramatically from the December 2001 version. At least some of the
    XMI Production of XML Schema references to the SOAP encoding are invalid.
    For example, they have replaced "href" with "ref" that apparently does not
    support URIs as values. There may be more changes; it will take some time
    to digest in its new form.

    Proposed resolution: Remove references to SOAP in the XMI Production of
    XML Schema specification. In a later revision, we can add corrected
    references back in.

  • Reported: XMI 1.2 — Thu, 23 May 2002 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Full compliance with XLink

  • Key: XMI13-18
  • Legacy Issue Number: 4707
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Now XLink is a W3C Recommendation, compliance is sensible. The aim should be
    that the XMI links can be procesed/managed by a generic XLInk processor. See
    Dave Carlson book 'Modeling Application with XML' (p135) for suggestions.

  • Reported: XMI 1.2 — Tue, 20 Nov 2001 05:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Use separate attribute for XMI vs data 'version'

  • Key: XMI13-14
  • Legacy Issue Number: 4641
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    4.5.3 Why not avoid the clash with the other "version" attribute by giving
    them different names e.g. "xmiversion"?

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Section 9.2.1 of the XMI production of XML Schema

  • Key: XMI13-16
  • Legacy Issue Number: 4663
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    Section 9.2.1 of the XMI production of XML Schema has two sentences. The
    second sentence does not make sense as written.

  • Reported: XMI 1.2 — Mon, 5 Nov 2001 05:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    Clarify.

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Unclear software compliance

  • Key: XMI13-17
  • Legacy Issue Number: 4706
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Chapter 9 refers largely to the conformance of XMI Schemas and Documents and
    little regarding what it means for a software implementation/tool to be
    conformant (except points in 9.3 though it's not clear from their form).
    See similar issues for XMI 1.3 for suggested resolutions.

  • Reported: XMI 1.2 — Tue, 20 Nov 2001 05:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    See revised text

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Wrong cardinality in Schema for Difference.container reference

  • Key: XMI13-15
  • Legacy Issue Number: 4643
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    4.5.7: The schema appears to allow multiple values (xsd:IDREFS) for the
    'container' reference whereas the model is 0..1.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Describe Tags further

  • Key: XMI13-10
  • Legacy Issue Number: 4636
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    In general it would be useful to enhance the summary table in 4.10.1 to
    indicate the MOF constructs to which they apply. In general it would be
    useful to use the Profile notation introduced in UML 1.4: as if it were a
    "XMI Profile for MOF". It would be useful to do this at the MOF level and
    not confuse it with the use of UML.
    It would also be useful to indicate which tags expand and which contract
    the set of allowed output.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    add a section to summarize the scope of each tag, and the constructs affected.

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Level of required support for XPointer

  • Key: XMI13-12
  • Legacy Issue Number: 4639
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    It's not clear from section 4.9.2 exactly what the set of valid choices is:
    it should clarify the intention that any Xlink functionality is available
    and this section is offering some guidance. (However start of 4.9 states
    that Xlink is not required as a prerequisite).
    Support for full XPointer capabilities potentially places too great a
    burden on XMI importers (e.g. it could require a repository to support
    Xpointer as a query language): some level of optionality should be
    specified.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Clarify Management of Tags in MOF Models

  • Key: XMI13-11
  • Legacy Issue Number: 4637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 4.7.2 states that "enforceMin(Max)imumMultiplicity" should be
    attached to the MOF metamodel. This does not seem appropriate: the required
    validation is most likely to vary by import context, not be static for
    every application of the metamodel. The potential alternative of having a
    set of 'validation options' that can be specified as part of the import
    operation is that these options also affect the schema generated and need
    to be available to tools.
    The submitters have in mind use of separately packaged tag sets separate
    from the metamodel: these ideas should be explained.
    The specification should also explain a simple way for tools to know
    exactly what are the options used in an XMI document.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    Clarify by adding text

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Namespace logical identifiers should include version

  • Key: XMI13-13
  • Legacy Issue Number: 4640
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    4.7.1: if the logical namespace name is meant to be persistent and
    unchanging then surely it should include the version number. And arguably
    the XMI version since the namespace will differ between 1.1 and 2.0. (e.g.
    UML="org.omg/standards/UML/1.4/xmi2.0").

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    In the examples in section 4.7.1, use the new OMG directory structure

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Clearer support for data as well as metadata

  • Key: XMI13-9
  • Legacy Issue Number: 4635
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    Despite the 'Metadata' in its name, XMI has often been proposed as a
    model-driven approach to XML for Data interchange: this is also reflected
    in the car-related examples in the submission and indeed in the RFP
    (section 6.1.1).
    Is this valid and if so should it be reflected in the evaluation or even
    the name of the standard?
    For example, in 4.5.6 it should also be explained how the (Meta)Model
    elements are to be used (if at all) when the XMI file is being used for
    instance data (e.g. actual cars as opposed to the model for cars). I
    presume that the MetaModel element would refer to the Cars model and the
    Model element would somehow describe this set of cars (e.g. "Cars in the
    company car pool as of 1/1/2001"). It might be better if these element
    names were not wedded to the 4-layer approach: more generally "Model" would
    be better worded "Content" and "MetaModel" would be better named "Model"
    (i.e. the metadata for the content).
    It would help if the M2, M1, and M0 examples were given for the same model.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Generating both Attributes and Elements for MOF attributes/references

  • Key: XMI13-8
  • Legacy Issue Number: 4634
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    Section 4.7.4 generates both XML attribute and XML element definitions for
    appropriate MOF attributes - regardless of the MOF tag (or the default
    value) rom the metamodel.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    Add references to the "attribute", and "element" tags in section 4.10.1.

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Combined document structure unclear

  • Key: XMI13-7
  • Legacy Issue Number: 4633
  • Status: closed  
  • Source: gmail.com ( Barbara Price)
  • Summary:

    Though the document does say it builds on XMI 1.1 it's not clear how the 2
    specs are to be read together; neither does it seem complete as a new
    replacement XMI specification (e.g. it's missing some of the introduction
    and usage scenarios that are in the 1.1 spec). [NB should it not build on
    the "formal/" XMI 1.1 specification not the submitted one?]
    Neither the cumbersome name for the specification (which should be changed)
    and the headings used for the document do not help: for example section 4
    applies to XMI 2.0 schemas only.
    It might have been clearer to have 2 separate specifications: an add-on to
    XMI 1.1 that just added XMI 1.1-compliant Schema generation. And,
    separately, a complete stand-alone specification for XMI 2.0.

  • Reported: XMI 1.2 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Keeping pace with XMI 1.x and MOF 1.x

  • Key: XMI13-6
  • Legacy Issue Number: 4612
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    XMI for XML Schemas should attempt to keep up with agreed issue resolutions
    from XMI and MOF. This should not only include substantive changes but
    relevant interpretations and clarifications.
    In the short term there will be existing adopted changes in XMI 1.2 and MOF
    1.4.

    One option might be to keep a 'shadow' list of XMI/MOF resolved issues with
    an indication of whether there is an impact on XMI/XMI for XML Schemas and
    an indication of progress for the latter.

  • Reported: XMI 1.2 — Tue, 9 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Update Section 9.3.1 to reference Chapter 4

  • Key: XMI13-5
  • Legacy Issue Number: 4608
  • Status: closed  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    This issue was raised by Peter Walker from Sub during his Architecture
    Board evaluation of XMI Production of XML Schema. This is the only issue
    raised by the AB.

    Section 9.3.1 refers to Sections 6.5, 6.9, and 6.10. These sections should
    be 4.5, 4.9, and 4.10. Also, Jeff Mischkinsky suggested that the titles of
    the referenced sections be included in the revised text.

  • Reported: XMI 1.2 — Mon, 8 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:37 GMT

Aggregations are Undifferentiated

  • Key: XMI13-4
  • Legacy Issue Number: 4597
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Applying Production Rule 5i in 6.3.5 does not result in any indication as to
    the actual association/reference being used. If the example were extended to
    add another composite reference from Department to Employee called
    casualWorkers then there would be no way to differentiate casual workers
    from employees for a department in the XMI document.

  • Reported: XMI 1.2 — Sun, 7 Oct 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.3
  • Disposition Summary:

    The example (6-10) has a typo in it.

  • Updated: Sat, 7 Mar 2015 04:37 GMT