Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — Open Issues

  • Acronym: MOF
  • Issues Count: 127
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
MOF26-40 CMOF constraint OCL for ownedEnd is too restrictive MOF 2.5 open
MOF2RDF11-1 Not able to download documents MOF2RDF 1.0 open
MOF26-39 Wrong import of the MOF::Common package by the MOF::Reflection package: it's actually the opposite. MOF 2.5.1 open
MOF2RDF11-2 Normative Machine Readable Document links are broken MOF2RDF 1.0 open
MOF26-38 AnnexB: Links to Constraint OCL Files Crossed MOFVD 2.1 open
MOFM2T11-21 Typo MOFM2T 1.0 open
MOF26-37 Typographical error MOF 2.5.1 open
MOF26-35 org.omg.emof.oppositeRoleName MOF 2.5 open
MOF26-36 The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier MOF 2.5 open
MOF26-34 Conflicting statements about tag multiplicity MOF 2.5 open
QVT14-25 QVTo : Confusing isVirtual definition for imperative operation calls MOF 1.2 open
MOF26-33 MOF Versioning & Development Lifecycle Spec (MOF VD) 2.0: How are VersionedExtents created? MOFVD 2.1 open
MOF26-32 MOF2 Versioning Issue: Include annotated examples from presentation MOFVD 2.0b1 open
MOF26-30 Incomplete URIStore definition MOFFOL 2.0b1 open
MOF26-31 Migration of package relationships MOFFOL 2.0b1 open
MOF26-29 Need to specify URI structure MOFFOL 2.0b1 open
MOF26-26 MOF Facility Object Lifecycle (MOF FOL) 2.0: inconsistency about Facility::getWorkspace() MOFFOL 2.0b1 open
MOF26-27 Section 7 of formal/2010-03-04 MOFFOL 2.0b1 open
MOF26-28 Issues on MOF Facility formal/10-03-04 MOFFOL 2.0b1 open
MOF26-24 MOF Facility Object Lifecycle (FOL) 2.0: Is there a URIStor or not? MOFFOL 2.0b1 open
MOF26-25 MOF Facility Object Lifecycle (FOL) 2.0: 6.4.2 Session does not appear in any diagram MOFFOL 2.0b1 open
MOF26-20 MOF should publish a convenience document that pre-merges all the different packages MOF 2.4 open
MOF26-18 Key Qualifiers Missing in MOF MOF 1.4 open
MOF26-19 MOF 2.0 Core: Exceptions missing for CMOF Reflective operations MOF 1.4 open
MOF26-23 Incomplete simplification & alignment between UML & MOF in 2.4: MOF::Extension::Tag MOF 2.4 open
MOF26-22 Error in specified return value MOF 2.4.1 open
MOF26-17 Section: 10.3 MOF 2.0 open
MOF26-16 CMOF should not itnore visibilities MOF 1.4 open
MOF26-21 MOF issue - MOF says nothing about the semantics of operation redefinition MOF 2.4 open
MOF26-6 The text is not clear MOF 2.4.1 open
MOF26-3 Does MOF::Reflection::Object own "invoke" Operation ? MOF 2.4 open
MOF26-2 Sentence fragment duplication MOF 2.4 open
MOF26-4 Missing a right brace MOF 2.4 open
MOF26-5 Missing a right brace MOF 2.4 open
MOF26-13 MOF does not have the correct semantics for links in the presence of association specialization MOF 2.4 open
MOF26-15 Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties MOF 2.0 open
MOF26-7 Section 2: Add references to MOF 2 XMI and MOF 3 IDL to clause 3. MOF 2.4 open
MOF26-9 There is an inconsistency in the current spec between link equality and link delete MOF 2.4 open
MOF26-10 There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects MOF 2.4 open
MOF26-8 Section 9.2 constraints MOF 2.4 open
MOF26-11 URIExtent should provide the capability of accessing links as well as elements by URI MOF 2.4 open
MOF26-14 There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15 MOF 2.0 open
MOF26-12 Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1 MOF 2.0 open
MOF26-1 as root Model element ? MOF 2.4 open
QVT14-14 Rationalize title MOF 1.2 open
QVT14-15 Trace Record not suitable for Incremental Execution MOF 1.2 open
QVT14-20 QVTo: What are the operation overloading semantics? MOF 1.2 open
QVT14-18 QVTo: Enhance Status to support access to nested transformation trace data MOF 1.2 open
QVT14-19 QVTo: Eliminate deprecated Typedef class MOF 1.2 open
QVT14-22 QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL MOF 1.2 open
MOFM2T11-13 Wrong concrete syntax (in EBNF) MOFM2T 1.0 open
MOFM2T11-12 Useful only as a proof of concept, hard to maintain for big projects MOFM2T 1.0 open
MOFM2T11-9 Provide a way for users to get the iteration count in a for loop MOFM2T 1.0 open
MOFM2T11-8 Example ambiguity MOFM2T 1.0 open
MOFM2T11-18 Inconsistency in metamodel Message MOFM2T 1.0 open
MOFM2T11-17 Section: 7.2, 7.3, A3 OCLExpression MOFM2T 1.0 open
MOFM2T11-16 Ambiguity detected in Invocation rule Message MOFM2T 1.0 open
MOFM2T11-14 Section: 8.2 MOFM2T 1.0 open
MOFM2T11-19 Issue: Typos in examples MOFM2T 1.0b1 open
MOFM2T11-15 Specification error in concrete syntax MOFM2T 1.0 open
MOFM2T11-10 Wrong relation in input model MOFM2T 1.0 open
MOFM2T11-11 abstract metaclasses should be italic MOFM2T 1.0 open
MOFM2T11-2 set of problems with the currently described operations MOFM2T 1.0 open
MOFM2T11-1 Missing reference MOFM2T 1.0 open
MOFM2T11-5 File unique id is not useable MOFM2T 1.0 open
MOFM2T11-4 current version of the specification doesn't allow for any "post-processing" of the generated text. MOFM2T 1.0 open
MOFM2T11-3 Section: 7.3, 8.1, 8.1.17 MOFM2T 1.0 open
MOFM2T11-7 Add an attribute to the files block for users to specify generated file's encoding MOFM2T 1.0 open
MOFM2T11-6 Typos/issues in the examples MOFM2T 1.0 open
MOF14-81 WG: Attribute accessors and mutators MOF 1.2 open
MOF14-83 mof rtf issue - coverage of RefXXX interfaces by MOF metamodel MOF 1.2 open
MOF14-82 mof rtf issue - setting UUIDs MOF 1.2 open
MOF14-66 Tags that parameterize a meta-model mapping MOF 1.2 open
MOF14-65 What is a UML "profile"? MOF 1.2 open
MOF14-62 MOF RTF Isue: Conflict between "Facility" and "Package Object " MOF 1.2 open
MOF14-61 Generated operations returning attributes/references should not raise Cons MOF 1.2 open
MOF14-64 Semantics of Reference "set" onto an ordered Association. MOF 1.2 open
MOF14-63 ModelElement needs to have permanent, unique, unchanging, identifier MOF 1.2 open
MOF14-78 Provide tools to chapter 5 UML 1.3R9 draft MOF 1.2 open
MOF14-77 Should Reflective.DesignatorType be "string"? MOF 1.2 open
MOF14-80 Do non-public Attributes need initialising? MOF 1.2 open
MOF14-79 IDL for Reflective Package Interfaces can conflict MOF 1.2 open
MOF14-72 Specify the semantics of Constraint verification MOF 1.2 open
MOF14-71 Add appropriate Attribute default values to the MOF Model MOF 1.2 open
MOF14-76 MOF Model IDL versus OMG Style guidelines MOF 1.2 open
MOF14-75 Need for light-weight References MOF 1.2 open
MOF14-74 Add a new technical overview chapter between chapters 2 and 3" MOF 1.2 open
MOF14-73 Freezing mechanism for all models MOF 1.2 open
MOF14-69 Add support for Exception generalization MOF 1.2 open
MOF14-67 Validate the OCL constraints in the MOF specification MOF 1.2 open
MOF14-68 Add support for default values to MofAttribute MOF 1.2 open
MOF14-70 Define a MOF Class that is the supertype of all Classes MOF 1.2 open
MOF14-35 "exposedEnd" for any of the references in the MOF metamodel. MOF 1.4 open
MOF14-34 Association Generalization Proposal MOF 1.4 open
MOF14-33 Unnecessary constraint on import by nested packages MOF 1.4 open
MOF14-31 Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong MOF 1.4 open
MOF14-30 Restrictions needed for nested Packages and Classes MOF 1.4 open
MOF14-28 Looking up metaobject using MOFID MOF 1.4 open
MOF14-27 resolveQualifiedName operation MOF 1.4 open
MOF14-25 Deprecate object inheritance of class proxy interface MOF 1.4 open
MOF14-24 Alignment of reflective interfaces with JMI MOF 1.4 open
MOF14-29 Navigability of assoc. ends in MOF model MOF 1.4 open
MOF14-26 Remove obsolete material MOF 1.4 open
MOF14-23 Tracking identity of replicated / interchanged metadata MOF 1.4 open
MOF14-32 Multiplicity be optional for non-navigable association ends. MOF 1.4 open
MOF14-10 The Metadata architecture needs to move away from the 4 levels and labels MOF 1.3 open
MOF14-9 Specify XMI parameters for the MOF / XMI interchange format MOF 1.3 open
MOF14-19 Delete all non-MOF-specific terms from the Glossary MOF 1.3 open
MOF14-18 Add 'semantics' attribute to Operation. MOF 1.3 open
MOF14-16 The current MOF package level import is not sufficient MOF 1.3 open
MOF14-15 MOF-RTF issue: AttachesTo.modelElement - ordered MOF 1.3 open
MOF14-22 mof-rtf issue: Association Generalization MOF 1.4 open
MOF14-21 Modeling OCL Helper Functions MOF 1.4 open
MOF14-13 The role name of the Namespace->ModelElement association end MOF 1.3 open
MOF14-12 role is named 'containedElement' while the reference is named 'contents' MOF 1.3 open
MOF14-20 Representation of constraints MOF 1.4 open
MOF14-11 predefined tag for marking attributes to act as qualifier in classifier MOF 1.3 open
MOF14-17 Disallow null instance values MOF 1.3 open
MOF14-14 MOF IDL rules to minimize network roundtrips MOF 1.3 open
MOF14-5 MOF 1.3 Why prevent nonpublic Associations? MOF 1.3 open
MOF14-4 MOF 1.3 IDL template for clustering uses wrong name MOF 1.3 open
MOF14-2 Template should suppress add for [x..x] Attributes MOF 1.3 open
MOF14-1 MOF and IDL repository ids MOF 1.3 open
MOF14-8 Reflective interface for Package factory MOF 1.3 open
MOF14-7 Minor changes to some Reflective operations MOF 1.3 open
MOF14-3 MOF specifies no interfaces for actually (de-)serializing a model MOF 1.3 open
MOF14-6 MOF 1.3 Package should subtype Classifier MOF 1.3 open

Issues Descriptions

CMOF constraint OCL for ownedEnd is too restrictive

  • Key: MOF26-40
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The OCL is as follows. The restriction that ownedEnd->size() < 2 is not justified by the text of the constraint nor the specification, which refer only to memberEnds and size being limited to 2.
    In fact associations which own both their ends are a frequently used and useful (e.g. to link 2 independnetly developed (meta)models.
    The constraint should be ownedEnd->size() <= 2.

    >>>>>>>>>>>>>>
    – 14.3 [1] The multiplicity of Association::memberEnd is limited to 2 rather than 2..* (i.e., n-ary Associations are not supported);
    – unlike EMOF, CMOF associations can have navigable association-owned ends.
    – see also: https://sites.google.com/site/metamodelingantipatterns/catalog/mof/association-does-not-have-two-member-ends

    context Association
    inv CMOF_14_3_1: memberEnd->size() = 2 and ownedEnd->size() < 2

    <<<<<<<<<<<<<<<

  • Reported: MOF 2.5 — Tue, 3 May 2022 15:29 GMT
  • Updated: Tue, 3 May 2022 16:56 GMT

Not able to download documents

  • Status: open   Implementation work Blocked
  • Source: Statnett SF ( Svein Olsen)
  • Summary:

    Hi,
    I am able to download the Specification, but not any of the Normative Machine Readable Documents. I assume they are collected in a zip file, but non of the item it pointing to this zip file.

    Best regards,
    ¨Svein

  • Reported: MOF2RDF 1.0 — Sat, 18 Jul 2020 18:02 GMT
  • Updated: Fri, 29 Apr 2022 01:03 GMT

Wrong import of the MOF::Common package by the MOF::Reflection package: it's actually the opposite.

  • Key: MOF26-39
  • Status: open  
  • Source: None (independent IT engineer) ( Vincent Guyon)
  • Summary:

    No import of the MOF::Common package is required by the MOF::Reflection package.
    It's actually the opposite because the MOF::Common::ReflectiveCollection class inherits from the MOF::Reflective::Object (cf. Figure 10.2 on page 19).
    The problem is also present in the MOF/20131001/MOF.xmi (ptc/14-08-10) document.

    Another problem in the document: the 10.4 sub-chapter describing the MOF::Common package should not be a sub-chapter of the MOF::Identifiers main chapter (chapter 10), but in a specific main chapter for itself (chapter 11).

  • Reported: MOF 2.5.1 — Sun, 17 Apr 2022 11:40 GMT
  • Updated: Thu, 21 Apr 2022 16:11 GMT


AnnexB: Links to Constraint OCL Files Crossed


Typo

  • Status: open  
  • Source: none ( Franz)
  • Summary:

    Typo in the EBNF `OclExpessionCS` instead of `OclExpressionCS`

  • Reported: MOFM2T 1.0 — Fri, 18 Oct 2019 14:22 GMT
  • Updated: Tue, 22 Oct 2019 19:49 GMT

Typographical error

  • Key: MOF26-37
  • Status: open  
  • Source: Private individual ( Daniel Flaum)
  • Summary:

    The word 'metamodel' is misspelled as 'meatmodel' in the lower-most paragraph of page 1. The sentence which contains it is:

    "The lightweight subset representing the MOF meatmodel is specified by specifying constraints against the UML metamodel."

  • Reported: MOF 2.5.1 — Tue, 1 Oct 2019 19:11 GMT
  • Updated: Tue, 8 Oct 2019 17:44 GMT

org.omg.emof.oppositeRoleName

  • Key: MOF26-35
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The oppositeRoleName tag was introduced to support inverse navigation by OCL expressions since an OCL navigation needs to know the name to be navigated. An OCL navigation also needs to know whether the far end is a collection or not, and, if it is a collection, whether it is ordered and/or has unique values.The vast majority of opposite end characteristics can be reconstructed by assuming [0..1] !ordered, unique. However for the UML 2.5 model, this erroneously characterizes one ordered collection as not-ordered, about 10 lower bounds as 0 rather than 1, and about 100 upper bounds as 1 rather than 2 or *.

    If EMOF is to be useable by OCL and related tools, additional
    org.omg.emof.oppositeLower
    org.omg.emof.oppositeUpper
    org.omg.emof.oppositeOrdered
    org.omg.emof.oppositeUnique

    tags are need to avoid corruption of metamodel relationships.

    (The discussion on Issue 12800 that introduced oppositeRoleName suggested that the above might be necessary. Experience has shown that they are necessary. For instance for QVTr, a QVTc middle metamodel is synthesized with unidirectional navigation to the user metamodels. These unidirectional relationships are navigated in reverse as part of the trace and must have correct multiplicities.)

  • Reported: MOF 2.5 — Tue, 17 May 2016 14:18 GMT
  • Updated: Sat, 28 Jan 2017 10:13 GMT

The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier

  • Key: MOF26-36
  • Status: open  
  • Source: Object Management Group ( Juergen Boldt)
  • Summary:

    The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier. The sentence currently reads:

    The OCL constraints limiting this metamodel to the MOF 2 - relevant subsets are defined in Clause for EMOF and Clause for CMOF. A reference to files with the OCL source code is provided in Annex.

    There should be a number after "Clause" both times it appears ("12" and "14", perhaps?) and a letter at the end following Annex ("B"?).

  • Reported: MOF 2.5 — Fri, 5 Aug 2016 21:11 GMT
  • Updated: Fri, 5 Aug 2016 21:16 GMT

Conflicting statements about tag multiplicity

  • Key: MOF26-34
  • Status: open   Implementation work Blocked
  • Source: gmail.com ( Florian Schneider)
  • Summary:

    The model in Figure 11.1 ("The Extension package") does not specify a multiplicity for the tag property of MOF::Reflection::Element

    That is in conflict with one sentence in Section 11.1
    "The MOF Extension capability provides a simple mechanism to associate a collection of name-value pairs with model elements in order to address this need."

    and in Section 11.2
    "A model element can be associated with many Tags"

    Just as a sidenote, the two sections have two other issues:
    1) 11.2 is stating that "A model element cannot have more than one tag with the same name." but there is no OCL constraint to formalize that
    2) The property owner:Element [0..1] mentioned in 11.2 is not mentioned on Figure 11.1

  • Reported: MOF 2.5 — Sat, 16 Apr 2016 18:08 GMT
  • Updated: Wed, 27 Apr 2016 14:17 GMT

QVTo : Confusing isVirtual definition for imperative operation calls

  • Key: QVT14-25
  • Status: open  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    The ImperativeCallExp::isVirtual attribute is defined as follows: "Unless isVirtual is true, this invocation is virtual." This is extremely counter-intuitive and apparently stems from a careless renaming. As a result, virtual call semantics are disabled by default, because the default value 'true' implies that an operation is "statically called". The default should be virtual call semantics, so the description should be turned around.

  • Reported: MOF 1.2 — Thu, 11 Feb 2016 13:01 GMT
  • Updated: Wed, 13 Apr 2016 08:20 GMT

MOF Versioning & Development Lifecycle Spec (MOF VD) 2.0: How are VersionedExtents created?

  • Key: MOF26-33
  • Legacy Issue Number: 18905
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The MOF Facilities Object Lifecycle (MOF FOL) 2.0 spec defines "factory" methods in MOFFOL::Facility::createExtent(…)

    This method can create either an Extent or a URIExtent.

    MOF VD defines VersionedExtent as a specialization of URIExtent and Extent.
    However MOF VD provides no operation for creating a VersionedExtent.
    Are are such entities to be created?

  • Reported: MOFVD 2.1 — Wed, 11 Sep 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:44 GMT

MOF2 Versioning Issue: Include annotated examples from presentation

  • Key: MOF26-32
  • Legacy Issue Number: 9810
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The slides produced by Geoff Clemm for the submission presentation were very helpful and should be included in the specification itself along with a bit of detail as to how they relate to the metamodel

  • Reported: MOFVD 2.0b1 — Thu, 8 Jun 2006 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:44 GMT

Incomplete URIStore definition

  • Key: MOF26-30
  • Legacy Issue Number: 15642
  • Status: open  
  • Source: Anonymous
  • Summary:

    The diagram on p6 includes URIStore but with incomplete lines.

    There is no subsection for it in 6.2.

  • Reported: MOFFOL 2.0b1 — Sun, 26 Sep 2010 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Migration of package relationships

  • Key: MOF26-31
  • Legacy Issue Number: 6909
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Summary:
    At MOF 1.4, packages can be related through:

    • import
    • nesting
    • inheritance
    • clustering
      We haven't really addressed this aspect of migration which should be added to Chapter 9.
      Personally I think there's little value in MOF 1.4 nesting and inheritance relationships and they're infrequently used in real metamodels (if people know what they're doing - occasionally people nest packages in UML Profile for MOF without realizing the implications).

    In UML2 though we do still have a nesting relationship between packages so should consider the implications in terms of MOF constraints and extents.

    Conversely we no longer have clustering (the most useful relationship in MOF 1.4) though we do have merging (with 2 flavors): we need to consider the runtime implications of instantiating a package that merges other packages. Is it the same as clustering?

  • Reported: MOFFOL 2.0b1 — Thu, 15 Jan 2004 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Need to specify URI structure

  • Key: MOF26-29
  • Legacy Issue Number: 6904
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Summary:
    isID semantics - the 'may be used' is too weak. I think myself and Joaquin have made the point that we
    need to specify the URI structure to get interoperability (and I don't mean the W3C standard - I mean how to construct
    the URI from the objects/extents/properties/containers being identified).

  • Reported: MOFFOL 2.0b1 — Thu, 15 Jan 2004 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

MOF Facility Object Lifecycle (MOF FOL) 2.0: inconsistency about Facility::getWorkspace()

  • Key: MOF26-26
  • Legacy Issue Number: 18901
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The overview diagram in section 6.2 shows an operation:

    Facility::getWorkspace(id : String[0..1]) : Workspace

    However, section 6.2.1.3 describes an operation with a different signature:

    Facility::getWorkspace(id : String[0..1]) : Workspace[0..*]

    Which is it?

  • Reported: MOFFOL 2.0b1 — Wed, 11 Sep 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Section 7 of formal/2010-03-04

  • Key: MOF26-27
  • Legacy Issue Number: 15647
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    2. Section 7 should be applied to the other specifications not left in this specification

  • Reported: MOFFOL 2.0b1 — Sun, 26 Sep 2010 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Issues on MOF Facility formal/10-03-04

  • Key: MOF26-28
  • Legacy Issue Number: 15643
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    1. The figures should have numbers and captions

  • Reported: MOFFOL 2.0b1 — Sun, 26 Sep 2010 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

MOF Facility Object Lifecycle (FOL) 2.0: Is there a URIStor or not?

  • Key: MOF26-24
  • Legacy Issue Number: 18903
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The figure in section 6.2 shows a URIStore class with two broken lines (associations? Generalizations? Something else?)
    There is no entry for URIStore in the spec but there is a reference to it in 6.2.1.3:

    Facility::createStore(name : String, contextURI : String[0..1], ….)

    The description of the contextURI parameter says:

    The URI to be used to address this Store. If specified, an instance of URIStore will be created.

    So, is there a URIStore metaclass in MOF FOL or not?

  • Reported: MOFFOL 2.0b1 — Wed, 11 Sep 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

MOF Facility Object Lifecycle (FOL) 2.0: 6.4.2 Session does not appear in any diagram

  • Key: MOF26-25
  • Legacy Issue Number: 18902
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    MOF Facility Object Lifecycle (FOL) 2.0: 6.4.2 Session does not appear in any diagram

  • Reported: MOFFOL 2.0b1 — Wed, 11 Sep 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

MOF should publish a convenience document that pre-merges all the different packages

  • Key: MOF26-20
  • Legacy Issue Number: 19613
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    MOF should publish a convenience document that pre-merges all the different packages

  • Reported: MOF 2.4 — Thu, 18 Sep 2014 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Key Qualifiers Missing in MOF

  • Key: MOF26-18
  • Legacy Issue Number: 8695
  • Status: open  
  • Source: SAP SE ( Axel Uhl)
  • Summary:

    MOF has always lacked the capabilities to navigate an association
    qualified by the values of properties of the end to which to navigate.
    This has been a feature in UML since at least UML 1.3. When implementing
    MOF, this leads to the unpleasant effect that in order to pick elements
    from a collection returned from navigating a to-many association
    requires iterating over all elements returned and filtering for the ones
    meeting the desired criteria. The way MOF works, this makes it
    impossible to provide an efficient implementation that yet is
    standard-compliant.

    Key qualifiers address exactly this issue. However, when the UML was
    split into infrastructure and superstructure, this valuable UML feature
    was placed into the superstructure, thus not being accessible by the MOF
    specification. MOF itself doesn't provide its own approach to qualified
    navigation either.

    A concrete example of why the current situation is less than optimal is
    the UML with its association between Namespace and NamedElement, using
    role names "ownedMember" and "namespace." When navigating to a member of
    a namespace with a particular name, one has to enumerate all elements
    owned by that namespace and compare its name with the name looked for.
    The effort scales with the number of elements contained by that
    namespace, and there is no way for a repository to provide an efficient
    implementation for that in a standard-compliant way.

    A fix for this problem would be to move the association from
    UML::Classes::AssociationClasses::Property to itself with properties
    named "qualifier" and "associationEnd" to
    InfrastructureLibrary::Core::Basic and connect it to
    InfrastructureLibrary::Core::Basic::Property instead. With this, MOF2
    could use this useful feature, and a language binding for MOF2 could use
    this to offer qualified navigation. Repository implementations may
    provide a naive implementation at least, whereas advanced repositories
    may use the opportunity to maintain internal index structures that
    facilitate performant qualified access.

    I don't know whether this changes anything in the way an issue is
    handled by the OMG, but I've already talked to several vendors, current
    MOF implementors and active OMG contributors (also see Cc list), and
    there is wide consensus that this would be a very helpful change.

  • Reported: MOF 1.4 — Mon, 11 Apr 2005 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF 2.0 Core: Exceptions missing for CMOF Reflective operations

  • Key: MOF26-19
  • Legacy Issue Number: 8268
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    In ptc/04-10-15, Chapter 9 (EMOF Reflection) has some limited exceptions defined but Chapter 13 (CMOF Reflection) has none

  • Reported: MOF 1.4 — Fri, 11 Feb 2005 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Incomplete simplification & alignment between UML & MOF in 2.4: MOF::Extension::Tag

  • Key: MOF26-23
  • Legacy Issue Number: 19239
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The simplification and alignment between UML and MOF in the 2.4 series is incomplete.
    In particular, the extensions that MOF adds to UML are missing in UML.
    The MOF extensions that are missing in UML mean that statements like the one below in UML 2.5, section 6.2 are technically incorrect:

    Since version 2.4.1 a MOF 2.x metamodel, including the UML 2.x metamodel, is a valid UML 2.x model. This was a substantial simplification and alignment compared to earlier versions. It is expected that future versions of MOF and UML will continue to be aligned in this manner.

    For example, UML has no mechanism to specify the information about MOF::Extension::Tag. Without this information, it is currently not possible to fully rely on the above statement to use UML as a language for representing models of UML itself or parts of it such as the PrimitiveTypes library.

    One fairly simple option would be to define a MOF profile with stereotypes corresponding to the contents of the MOF-specific extensions of UML

  • Reported: MOF 2.4 — Fri, 14 Feb 2014 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Error in specified return value

  • Key: MOF26-22
  • Legacy Issue Number: 19131
  • Status: open  
  • Source: Student ( Jean-Luc Amitousa Mankoy)
  • Summary:

    The uml diagram in chapter 10.4 MOF:Common specifie that ReflexiveCollection remove method return a Boolean. Just after, when describing this method (chapter 10.5) it is set to Object.

  • Reported: MOF 2.4.1 — Thu, 28 Nov 2013 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Section: 10.3

  • Key: MOF26-17
  • Legacy Issue Number: 9018
  • Status: open  
  • Source: TCS ( Asha Rajbhoj)
  • Summary:

    As per MOF specification only one property can be id. isID defines Id property for Class. Query is... 1) IF I have a Class say "Class1" which has property say "prop1" which is defined as Id. And there is "Class2" which inherits from "Class1" Then 1)Does "Class2" also inherit Id of "Class1"? 2)Can "Class2" has its owned id property? like overiding id property etc? Basically in specification there is no mention of relationship between inheritance of Classes and there id properties. 2) Also we see a single id property is too restrictive. In fact for the UML Meta model's Classes we could not define any single property as a identifying property. Is there any plan to make multiple properties as identifier in MOF?

  • Reported: MOF 2.0 — Tue, 27 Sep 2005 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

CMOF should not itnore visibilities

  • Key: MOF26-16
  • Legacy Issue Number: 8997
  • Status: open  
  • Source: International Business Machines ( Jim Amsden)
  • Summary:

    Constraint [7] in section 14.3 of the MOF2 specification says that visibilities will be ignored, everything is assumed to be public, and name classes are possible and should be avoided. This constraint also appears in section 12.4 EMOF Constraints, constraint [4]. This is necessary for EMOF because it does not support package import or visibility. However, CMOF, which is based on InfrastructureLibrary Constructs does support both package import, namespace visibility, and visibility kind. It is not clear why CMOF would define visibility and then introduce a rule to ignore it. Perhaps this rule should be relaxed.

  • Reported: MOF 1.4 — Mon, 19 Sep 2005 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF issue - MOF says nothing about the semantics of operation redefinition

  • Key: MOF26-21
  • Legacy Issue Number: 18811
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    UML uses operation redefinition quite extensively, but MOF says nothing about what this means, and UML itself leaves it rather open – see for example issues 17924 and 15499. UML 2.5 beta leaves it even more open than 2.4.1, which means that MOF needs to be specific for UML to be well-defined.

    My suggestion is that MOF requires parameters in redefined operations to have the same number, type, multiplicity, uniqueness and ordering as the parameters in the operation being redefined.

  • Reported: MOF 2.4 — Wed, 10 Jul 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

The text is not clear

  • Key: MOF26-6
  • Legacy Issue Number: 19759
  • Status: open  
  • Source: UFES ( Halysson Freitas)
  • Summary:

    The portion of text ""An Extent is a context in which an Element in a set of Elements in a set can be identified"".
    I think that this way is better: ""An Extent is a context in which an Element in a set of Elements can be identified""

    That way, I can understanding. To more detail, in my language (portuguese), the Google shows a concise translation.

  • Reported: MOF 2.4.1 — Sat, 16 May 2015 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Does MOF::Reflection::Object own "invoke" Operation ?

  • Key: MOF26-3
  • Legacy Issue Number: 19872
  • Status: open  
  • Source: Anonymous
  • Summary:

    Regarding to spec:
    §13.4 Object (from CMOF Reflection)
    "CMOF Reflection adds the following extra operations.
    invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*]"

    But this operation is present into http://www.omg.org/spec/MOF/20131001/MOF.xmi file for MOF::Reflection::Object :

    <packagedElement xmi:type="uml:Class" name="Object" xmi:id="_MOF-Reflection-Object">
    ...
    <ownedOperation xmi:type="uml:Operation" name="invoke" visibility="public" xmi:id="_MOF-Reflection-Object-invoke">
    ...
    </ownedOperation>

    Moreover it uses <type xmi:idref="_MOF-CMOFReflection-Argument"/> from CMOF.

    Thanks

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Sentence fragment duplication

  • Key: MOF26-2
  • Legacy Issue Number: 19871
  • Status: open  
  • Source: Anonymous
  • Summary:

    The text "An Extent is a context in which an Element in a set of Elements in a set can be identified." contains sentence fragment duplication.

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Missing a right brace

  • Key: MOF26-4
  • Legacy Issue Number: 19861
  • Status: open  
  • Source: Anonymous
  • Summary:

    The where clause is lack of a right brace for the Outer relation definition.

  • Reported: MOF 2.4 — Mon, 30 Nov 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Missing a right brace

  • Key: MOF26-5
  • Legacy Issue Number: 19860
  • Status: open  
  • Source: Anonymous
  • Summary:

    The example given for transformation, i.e., "transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {" is lack of a right brace.

  • Reported: MOF 2.4 — Mon, 30 Nov 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF does not have the correct semantics for links in the presence of association specialization

  • Key: MOF26-13
  • Legacy Issue Number: 16270
  • Status: open  
  • Source: Anonymous
  • Summary:

    In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF 2.4 seems to be silent on the semantics of association generalization.

    According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: “Each instance of the specific classifier is also an indirect instance of the general classifier.”

    However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics.

    Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply.

    But there is a problem. Let’s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval. That gives anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug.

    In summary, the CMOF API that allows links to be explicitly manipulated and navigated should be defined so that a link of a sub-association is also a link of its super-associations.

  • Reported: MOF 2.4 — Thu, 26 May 2011 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties

  • Key: MOF26-15
  • Legacy Issue Number: 15833
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties, i.e., set, ordered set, bag and sequence

  • Reported: MOF 2.0 — Tue, 23 Nov 2010 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Section 2: Add references to MOF 2 XMI and MOF 3 IDL to clause 3.

  • Key: MOF26-7
  • Legacy Issue Number: 17632
  • Status: open  
  • Source: Anonymous
  • Summary:

    Clause 2 specifies a requirement that compliant products shall support certain technology mappings, but there is no reference either here or in Clause 3, Normative references, to sources of specifications of those mappings.

  • Reported: MOF 2.4 — Mon, 24 Sep 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

There is an inconsistency in the current spec between link equality and link delete

  • Key: MOF26-9
  • Legacy Issue Number: 17275
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    There is an inconsistency in the current spec between link equality and link delete. Link equality only checks for the end values and the association, whereas link delete says: “This may leave the same elements associated by other links for this Association”, implying more than one distinguishable link per pair of elements. This should be resolved according to the fact that in OCL and UML collections resulting from navigating associations can be bags, i.e. contain the same element more than once. Links must be distinguishable individually, not simply by equality of their ends. This will imply that links have some identity criteria: uuids would seem to fit the bill perfectly.

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects

  • Key: MOF26-10
  • Legacy Issue Number: 17274
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Section 9.2 constraints

  • Key: MOF26-8
  • Legacy Issue Number: 17395
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Section 9.2 contains a set of constraints – these should be rationalized with the ‘main” constraints in 12.4 (CMOF) and 14.3 (CMOF). A lot of them are in fact redundant (e.g. UML constraints) or not needed

  • Reported: MOF 2.4 — Thu, 24 May 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

URIExtent should provide the capability of accessing links as well as elements by URI

  • Key: MOF26-11
  • Legacy Issue Number: 17276
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    URIExtent should provide the capability of accessing links as well as elements by URI. This will enable SMOF multiply-classified links to be serialized with their uuids.

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15

  • Key: MOF26-14
  • Legacy Issue Number: 15828
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1

  • Key: MOF26-12
  • Legacy Issue Number: 15825
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

as root Model element ?

  • Key: MOF26-1
  • Legacy Issue Number: 19873
  • Status: open  
  • Source: Anonymous
  • Summary:

    The file http://www.omg.org/spec/MOF/20131001/MOF.xmi starts with:

    <xmi:XMI xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001">
    <packagedElement xmi:type="uml:Package" xmi:id="_MOF" name="MOF">
    ...

    Is it correct to have <packagedElement> as root Model element ?

    Why isn't it :

    <xmi:XMI xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001">
    <uml:Package xmi:id="_MOF" name="MOF">
    ...

    Thanks

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Rationalize title

  • Key: QVT14-14
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Pete Rivett, private email, requests removal of "2.0" from the "MOF 2.0 QVT 1.3" title.

    Two versions numbers are certainly confusing.

    But Isn't the "MOF" redundant too?

  • Reported: MOF 1.2 — Tue, 10 Nov 2015 17:02 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

Trace Record not suitable for Incremental Execution

  • Key: QVT14-15
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The glossary definition of Incremental Update strongly suggests that the trace necessary to execute a transformation is also suitable for incremental execution. This is a total falacy.

    Incremental execution of a Rule R with an input s must occur if any relevant property of s changes, which includes any property navigable from s. e.g. s.a.b.c.name. Therefore the trace for incremental execution must identify the identity and value of all accessed property values so that any change can influence re-execution.

    Since accessed values may be produced by another mapping, the trace must also record the identity and value of all assigned property values too.

    This affects all of QVTc, QVTr, and QVTo.

    For QVTo, a re-execution must repeat the accidental ordering of Set elements. Does the specification define an order or just require implementation magic? Is this then a determinstic form of asOrderedSet()?

  • Reported: MOF 1.2 — Wed, 28 Oct 2015 19:10 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: What are the operation overloading semantics?

  • Key: QVT14-20
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Does QVTo support operation overloading in a similar way to Java?

    How are conflicting contextual operations resolved when access semantics are used for import?

    How are conflicting contextual operations resolved when extension semantics are used for import?

    Is the resolution at run-time different to that at compile-time?

  • Reported: MOF 1.2 — Fri, 23 Oct 2015 09:21 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Enhance Status to support access to nested transformation trace data

  • Key: QVT14-18
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Transformation::transform()/parallelTransform() support a nested invocation but the returned Status content is very limited.

    Suggest 1: Reify TraceData/TraceRecord so that arbitrary OCL queries can be executed.

    Suggest 2: Add a getTraceData() to Status and 'this'.

    Suggest 3: Add an optional Status first argument to all resolve() methods to enable use on an invoked Transformation.

    NB. Since a transformation invocation involves cloning, resolve() should hide the clones so that the caller sees only a single object space.

    Suggest 4: TraceData/TraceRecord/Status/Transformation/Model should be / share share an abstraction with QVTc/QVTr.

  • Reported: MOF 1.2 — Wed, 14 Oct 2015 08:46 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Eliminate deprecated Typedef class

  • Key: QVT14-19
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVT13-89 for QVT13-10 deprecates Typedef. Remove it.

  • Reported: MOF 1.2 — Sat, 10 Oct 2015 22:06 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL

  • Key: QVT14-22
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 13082 - http://solitaire.omg.org/browse/QVT13-8 identifies the unsound relationship between ImperativeOCL and EssentialOCL.

    It offered a simple textual fix which was exploited to resolve the original issue.

    It also suggests a harder rework to establish modeling integrity. This issue forks off the rework not resolved by the original issue.

    (B) - (Major rework.) Rework the abstract syntax to reuse OCL
    expressions by composition rather than by inheritance.
    Imperative expressions ( => rename to 'statements' ) then may
    contain sub-statements and OCL expressions; OCL expressions
    are reused unchanged from the OCL spec (no imperative
    sub-expressions, no side-effects).
    These issues have been discussed on the MoDELS 2008 OCL Workshop,
    more details can be found at
    http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf

    (Since this is a breaking structural change, it is unlikely to happen before QVT 2.0)

  • Reported: MOF 1.2 — Mon, 5 Oct 2015 17:40 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

Wrong concrete syntax (in EBNF)

  • Legacy Issue Number: 19668
  • Status: open  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The concrete syntax as expressed in this chapter is full of errors

    1) It is a pity that it is not using the same EBNF idiom as other OMG specifications that were written before (e.g. IDL)

    2) It is a pity that the idiom selected is not consistantly applied (e.g. [...] or (...)? to describe an option - both are used sometimes even in the same rule)

    3) there are many literals that are missing their enclosing <> (e.g. extend_decl instead of <extend_decl>)

    4) there are some missing text separators (' here)

    5) and some typos such as Expession instead of Expression

    6) many (11) missing definitions

    7) the formatting of the whole section is weird, all in courier font, weird spacing... (a raw cut and paste?)

  • Reported: MOFM2T 1.0 — Fri, 28 Nov 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Useful only as a proof of concept, hard to maintain for big projects

  • Legacy Issue Number: 18994
  • Status: open  
  • Source: Rila ( Rusi Popov)
  • Summary:

    Dear colleagues,

    I have more than 13 years experience in MDD, MDA and code generation. Specifically the solution I built and use since more than 12 years is based on MOF 1.3/1.4, UML 1.3, XMI 1.1/1.2 using the NetBeans MetaData Repository as the only free and working standard implementation and able to be integrated with other tools.

    The problem: My experience shows that a code generation (M2T) framework should:

    • provide powerful text parsing and formatting features.
      For example: page 4 shows an example to generate a Java class with some attributes, just putting their names in the output. In practice:
      • the names of the classes and attributes rarely would be formatted as of the Java naming conventions (and in PIM they should not obey them)
      • the common java conventions state that for each attribute set/get methods might be generated in the format: get<attribute name with first capital letter> (OK, the toUpperFirst() function could help here)
      • the common Database conventions map the class attributes to fields where the separate words in the attribute name are all in upper case and separated by '_' i.e. the testAttribute is mapped to TEST_ATTRIBUTE column in the DB. The same is for class names and table names. Does M2T allow easily implementing this feature and easily maintaining it, considering the fact that in a real project it will be used many hundreds of times? I do not see features to create common functions / methods (other than macro with no result)
    • the structure of the models or metamodels to traverse is complex in MOF 1.4 & UML 1.3, it is incredibly more complex in MOF 2+ UML 2+. In such situations the procedural approach becomes complex and hard to maintain. In addition those structures are object-oriented i.e. use inheritance and polymorphic behaviour. Thus, the object-oriented approach to creating the template language would be more-appropriate to support object-oriented structures matching the structure of the metamodel.
    • the template language should allow extracting common logic / procedures (macros) and functions outside the templates and sharing the same logic in many templates. The best place would be a structure of classes, corresponding to the metamodel to process.
    • the template language should allow using control structures outside the templates themselves and initiate/apply them on model objects or results of queries on the model (i.e. collections of objects).
    • it seems to me that a more imperative approach to applying the templates than just using the types of the templates parameters would be easier to understand and maintain. Again, in a real case there are tens of templates nesting in each other, so maintaining implicitly their dependencies might be a real obstacle.
    • honestly, I think that it is too easy to implement some logic in an M2T template and then copy it hundred of times, which would make the support a real nightmare.

    About the normative example on page 27-:

    • the sample model to generate the DB description shows the primary and foreign keys as separate instances:
      • this is obviously a PSM, but the real benefits of MDA are gained when starting from PIM (there are no PK and FKs) and the generation of the intermediate PSM is a really rare practice. Many tools use the PIM and generate the code, scripts, DB schemas, deployment descriptors, etc. out of it. This both imposes more requirements on the M2T features (as of above) and just narrows the area of M2T application in its current state.
      • the example is deceptive, because it assumes that the class and attribute names will be the same as the table and field names. In real practice (see above) there are different naming conventions and in addition some DBs (like Oracle) impose maximum name length restrictions. In a complex model there may be overlapping names of FK constraints, sequence names, field names when reducing / abbreviating them from the human-readable PIM.
      • example 3 on page 30 demonstrates the weaknesses in the generation of the set/get method names - try the Java code conventions.
      • example 1 and 3 are deceptive because they just generate attributes, but do not show the complexity of associations support methods - try the generation of associations support methods for the cases of uni-directional and bi-directional associations in 1:1, 1:M and M:N multiplicity (not mentioning their composition and aggregation kinds). In the real case example I am working with there are 8 templates to generate such.
  • Reported: MOFM2T 1.0 — Tue, 8 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide a way for users to get the iteration count in a for loop

  • Key: MOFM2T11-9
  • Legacy Issue Number: 14557
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    MTL Currently specifies a "for-each" kind of loop, with no possibility for the user to know the index of the current iteration in the list of values they're iterating over.

    It would be nice to have access to an implicit variable within for loops to get this index. Something like

    [for (value : String | Sequence

    {'a', 'b', 'c'}

    )/]
    [i/] = [value/]
    [/for]

    would then generate text :

    1 = a
    2 = b
    3 = c

    I named this implicit variable "i" in this example, it could be named "iterationCount" or "iterationIndex" if we want to avoid conflicts... Yet I'd rather it be named "i" myself.

  • Reported: MOFM2T 1.0 — Tue, 13 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Example ambiguity

  • Key: MOFM2T11-8
  • Legacy Issue Number: 14438
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    Section 8.1.5 describes initSections and tells us that

    ---------8<---------
    An InitSection contains a set of variable initializations to be used in the body of its owning block.
    --------->8---------

    Yet example A.3 sports something like this :

    ---------8<---------
    [template public class_header(c : Class)

    { int count = -1; }

    ]
    [...]
    [for(a : Attribute) | c.attribute)

    { count = count + 1; }

    ]
    #define [a.name/]_BIT [count/]
    [/for]
    --------->8---------

    First of all, "int count = 1" is syntactically wrong and should be "count : Integer = -1"; but I've raised this in a separate issue not accepted yet so I don't have its number). The real problem here is that this example initializes a variable "count" in the template's init section, then tries to -modify this variable in the init section of a for.

    That just cannot be with the specification as it is now : the second init section should be "count : Integer = count +1" to be syntactically correct, and this doesn't mean "increment the value of 'count'" but "create variable 'count' with value 'count + 1' so we actually create a second variable that hides the first. Furthermore, as this second variable is declared on a for, and initSection's variables are only meant to be useable in the 'for' body, this second "count" variable will only last for an iteration. This means that every iteration, we create a new variable 'count' of value '0' (since the first 'count' variable is '-1').

    There is nothing in MOFM2T that's been specified as something that allows for the modification of a variable. We can only initialize them. Modifying variables requires the introduction of a non-generating block. Side-effect free blocks where we could do things without generating text.

    The next version should revise the A.3 example so as not to be misleading about the signification of InitSections. It should also introduce a new block dedicated to logic.

  • Reported: MOFM2T 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in metamodel Message

  • Legacy Issue Number: 12186
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    Title: Inconsistency in metamodel Message: The Mof2Text metamodel cannot attach static text to a body section. --------- ---------------------- | Block | 1 ---------> 0..* | TemplateExpression | --------- body ---------------------- --------- ---------------------- ----------------- | Block | -------|> | TemplateExpression | --------|> | OclExpression | --------- ---------------------- ----------------- The problem can be reproduced with the following example (extracted from Example 1. Page 25): [template public TableToDDL(t: Table)] CREATE TABLE [t.name/] ( [for (c:Column|t.column) separator(',')] [c.name/] [c.type/] [/for] ); [KeyToDDL(t.key)/] [ForeignKeyToDDL(t.foreignKey)/] [/template] The template body contains a ForBlock, a TemplateExpression ([t.name/]) and two TemplateInvocation (KeyToDDL and ForeignKeyToDDL). It seems that there are no ways to attach the static text portions "CREATE TABLE", "(" and ");" to the model. The OCL specification contains a StringLiteralExp class that could be used to attach this kind of static literal text. But for that to work, StringLiteralExp instances should be attachable somewhere, for instance, in the Block's body. In that case, perhaps that 'body' property could change its type from TemplateExpression to the more general OCLExpression, in order to allow StringLiteralExp's to be directly added to 'body', although this could be too much a general solution and would possibly require further testing. Solution: The metamodel could be change as follows: --------- ----------------- | Block | 1 ---------> 0..* | OclExpression | --------- body -----------------

  • Reported: MOFM2T 1.0 — Wed, 16 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.2, 7.3, A3 OCLExpression

  • Legacy Issue Number: 12184
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    Title: OCLExpression doesn't support the plus operator for string concatenations Message: The OCL specification defines (see 7.4: Basic Values and Types, page 10) the number of operations on the predefined types. The string type supports the concat, substring and size operations, but the plus operator is only used in integer types. The Mof2Text specification uses the plus operator to concatenate strings, and it's an error. Here there are some examples: 1. 7.2 Traceability --> [trace (c.id + '_definition') ] 2. 7.3 Directing Output to Files --> [file ('file:\\' + c.name + '.java', false, c.id + 'impl')] 3. A.3 Example 3 --> [file (c.name + '.cpp', false)] [trace (c.id + '.header')]

  • Reported: MOFM2T 1.0 — Wed, 16 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity detected in Invocation rule Message

  • Legacy Issue Number: 12176
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    The Mof2Text concrete syntax contain the following rules (see p. 22): <OclExpressionCS> ::= ( <PropertyCallExpCS> | <VariableExpCS> | <LiteralExpCS> | <LetExpCS> | <OclMessageExpCS> | <ifExp> | <invocation> ) <invocation> ::= ( <PathNameCS> '(' <actualarglist> ')' | 'super' ) [ <before> ] [ <separator> ] [ <after> ] <actualarglist> ::= ( <OclExpressionCS> ( ',' <OclExpressionCS> )* )? <before> ::= 'before' '(' <OclExpressionCS> ')' <separator> ::= 'separator' '(' <OclExpressionCS> ')' <after> ::= 'after' '(' <OclExpressionCS> ')' The OCL concrete syntax contain the following rules (see OCL Specificacion. Pages 64, 72, 80 and 81) OclExpressionCS ::= PropertyCallExpCS | VariableExpCS | LiteralExpCS | LetExpCS | OclMessageExpCS | IfExpCS PropertyCallExpCS ::= ModelPropertyCallExpCS | LoopExpCS ModelPropertyCallExpCS ::= OperationCallExpCS | AttributeCallExpCS | NavigationCallExpCS OperationCallExpCS ::= OclExpressionCS[1] simpleNameCS OclExpressionCS[2] | OclExpressionCS '->' simpleNameCS '(' argumentsCS? ')' | OclExpressionCS '.' simpleNameCS '(' argumentsCS? ')' | simpleNameCS '(' argumentsCS? ')' | OclExpressionCS '.' simpleNameCS isMarkedPreCS '(' argumentsCS? ')' | simpleNameCS isMarkedPreCS '(' argumentsCS? ')' | pathNameCS '(' argumentsCS? ')' | simpleNameCS OclExpressionCS argumentsCS[1] ::= OclExpressionCS ( ‘,’ argumentsCS[2] )? The conflict appears when the before, separator and after rules are all empty at the same time in the <invocation> MOF2Text rule. In that case the resolution proceeds as follows: OclExpressionCS ::= invocation ::= PathNameCS '(' actualarglist ')' OclExpressionCS ::= PropertyCallExpCS ::= ModelPropertyCallExpCS ::= OperationCallCS ::= pathNameCS '(' argumentsCS? ')' Solution: The best solution I have found to avoid this conflict involves the introduction of a new keyword, 'invoke'. The invocation rule could be updated as follows: <invocation> ::= invoke ( <PathNameCS> '(' <actualarglist> ')' | 'super' ) [ <before> ] [ <separator> ] [ <after> ] This way we can distinguish easily between the two cases. TemplateInvocation, MacroInvocation and QueryInvocation would then always resolve unambiguously into this last rule.

  • Reported: MOFM2T 1.0 — Tue, 15 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2

  • Legacy Issue Number: 11964
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    Grammar errors in section '8.2 concrete syxtax: syntax: ::= 'elseif' '(' <OclExpressionCS> ')' <production_code> ('/elseif') ? It should be: ::= 'elseif' '(' <OclExpressionCS> ')' <production_code> '/elseif' syntax: ::= '[else]' <production> ('[/else]')? It should be: ::= '[else]' <production> '[/else]'

  • Reported: MOFM2T 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Typos in examples

  • Legacy Issue Number: 11093
  • Status: open  
  • Source: TCS ( Sreedhar Reddy)
  • Summary:

    Issue: Typos in examples:
    In Annex A, A.1 Example 1:
    In the example fragment
    [template public SchemaToDDL (s: Schema)]
    [for (t:Table | s.table)]
    TableToDDL(t)
    [/for]
    [/template]

  • Reported: MOFM2T 1.0b1 — Fri, 8 Jun 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification error in concrete syntax

  • Legacy Issue Number: 12174
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    I've detected an error in the module rule of the concrete syntax section (8.2). This rule has an inconsistency with respect to the metamodel specified in section 8.1. The syntax is: <module_decl> ::= '[module' <PathNameCS> ‘(‘ <PathNameCS> ‘)’ [extends_decl] '/]' | 'module' <PathNameCS> [extends_decl] ---------- -------------- | Module | 0..* ---------> 1..* | TypedModel | ---------- -------------- So a Module can contain one or more TypedModels, but the grammar does not seem to provide ways to attach more than one. Solution: The module rule could be changed as follows: <module_decl> := '[module' <PathNameCS> ‘(‘ <PathNameCS> ( ‘,’ <PathNameCS>)* ‘)’ [extends_decl] '/]' | 'module' <PathNameCS> ‘(‘ <PathNameCS> ( ‘,’ <PathNameCS>)* ‘)’ [extends_decl]

  • Reported: MOFM2T 1.0 — Mon, 14 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong relation in input model

  • Legacy Issue Number: 16349
  • Status: open  
  • Source: Cassiopae ( Franck Michaux)
  • Summary:

    The class Department_fky has wrong relations, should be between class Employee and class Department_pky.

    [Employee : Table]

    {foreignKey}

    V
    [Department_fky : ForeignKey]

    {refersTo}

    v
    [Department_pky : Key]
    ^

    {key}

    [Department : Table]

  • Reported: MOFM2T 1.0 — Mon, 27 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

abstract metaclasses should be italic

  • Legacy Issue Number: 17267
  • Status: open  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    In the metamodel diagram in Section 8.1 NamedElement and ModuleElement should be written in italic letters because they are abstract metaclasses.

  • Reported: MOFM2T 1.0 — Thu, 22 Mar 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

set of problems with the currently described operations

  • Key: MOFM2T11-2
  • Legacy Issue Number: 13845
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    There are a set of problems with the currently described operations within the MOF Models to Text Transformation Language specification for the addition of new operations to extends the OCL standard library. Specifically, redundant, misleading or plain missing operations. >From now on I'll refer as "OCL specification" the following document : Object Constraint Language specification version 2.0 formal/06-05-01 . Likewise, "MTL specification" will refer to the following : MOF Models to Text Transformation Language version 1.0 formal/2008-01-16. I'll describe the aforementionned issues in three parts from now : A - Redundant operations "toUpper()" and "toLower()" operations are both specified for the String type in section 8.3.1 . Both of these are already defined in the OCL specification in section A.2.1.3 Table A.1 . They should then be removed from the MTL specification. B - Misleading operations Early adopters and testers of our implementation have confirmed that the "strtok(String, Integer) : String" as described in the MTL specification at section 8.3.1 isn't useable as is. Specifically, the integer flag makes it awkard to use : cannot be entirely used in a loop as they need to have the flag at "0" for the first call ... and plain weird to use in any other place, yet again because of this flag. Replacing this operation with a Java-like "tokenise" with no integer flag and returning the whole set of tokens would be easier to consume in a loop or use in templates/queries. C - Missing operations This is a different matter. The following list will consist on the one hand of things we found plain missing from the MTL specification and, on the other hand, of repetitive tasks our early adopters and testers have reported as bothersome to write in OCL and hindering the readability of scripts as a whole. First of all, the MTL specification describes a "substitute(String, String)" operation that can be used to "Substitute substring r in self by substring t and returns the resulting string.". From this we can say that three operations are missing from the spec (more details in the full list at the end of this report) : 1) substituteAll( String substring, String replacement ) : String 2) replace( String substring, String replacement ) : String 3) replaceAll( String substring, String replacement ) : String Further usage from these adopter and testers have shown that some usual operations are impossible (or plain bothersome) to write in OCL. These include (again, detailed description in the full list below) : String operations 4) startsWith( String substring ) : Boolean 5) endsWith( String substring ) : Boolean 6) trim( ) : String OclAny operations 7) ancestors( ) : Sequence(T) 8) ancestors( OclAny type ) : Sequence(T) 9) siblings( ) : Sequence(T) 10) siblings( OclAny type ) : Sequence(T) 11) descendants( ) : Sequence(T) 12) descendants( OclAny type ) : Sequence(T) Likewise, the "toString()" operation described in the MTL specification on both Real and Integer types isn't sufficient for a text generation language this same toString operation should be added to the standard type OclAny so that the user can obtain the String representation of each and every element. To sum this up, here is the full list of operations we would like to add to (or alter within) the MTL specification: C.1 - String operations C.1.a - modifications operation "strtok( String s1, Integer flag ) : String Breaks the string self into a sequence of tokens each of which is delimited by any character in string s1. The parameter flag should be 0 when strtok is called for the first time, 1 subsequently." should be altered to be "strtok( String s1, Integer flag ) : Sequence(T) Returns a sequence containing all parts of self split around delimiters defined by the characters in String delim." C.1.b - additions 1) endsWith( String substring ) : Boolean Returns true if self ends with the substring substring, false otherwise. 2) startsWith( String substring ) : Boolean Returns true if self starts with the substring substring, false otherwise. 3) substituteAll( String substring, String replacement ) : String Substitutes all substrings substring in self by substring replacement and returns the resulting string. If there is no occurrence of the substring, The original string is returned. substring and replacement are not treated as regular expressions. 4) replace( String substring, String replacement ) : String Substitutes the first occurence of substring substring in self by substring replacement and returns the resulting string. If there is no occurrence of the substring, The original string is returned. substring and replacement are treated as regular expressions. 5) replaceAll( String substring, String replacement ) : String Substitutes all substrings substring in self by substring replacement and returns the resulting string. If there is no occurrence of the substring, The original string is returned. substring and replacement are treated as regular expressions. 6) trim( ) : String Removes all leading and trailing spaces of self. C.2 - OclAny operations C.2.a - additions 7) ancestors( ) : Sequence(T) Returns all super-elements of self. 8) ancestors( OclAny type ) : Sequence(T) Returns all super-elements of self which type is equal to type. 9) siblings( ) : Sequence(T) Returns all siblings of self. 10) siblings( OclAny type ) : Sequence(T) Returns all siblings of self which type is equal to type. 11) descendants( ) : Sequence(T) Returns all direct and indirect children of self. 12) descendants( OclAny type ) : Sequence(T) Returns all direct and indirect children of self which type is equal to type. 13) toString( ) : String Returns the String representation of self.

  • Reported: MOFM2T 1.0 — Mon, 30 Mar 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing reference


File unique id is not useable

  • Key: MOFM2T11-5
  • Legacy Issue Number: 14434
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    In section 7.3, the file block of the MOF model to text transformation language is detailed. This section introduces the "uniqId" attribute of the file blocks which is meant to allow a tool to find back a generated file even if the object from which it's been generated changed significantly since the last generation.

    Though this is a good thing in theory, such an ID cannot be implemented whatever the programming language chosen. Or rather, it cannot be implemented in a satisfying way. Let's assume we have this file block :
    [file ('c:/'.concat(class.name).concat('.c'), false, class.id)]

    So a file "class.c" will be generated at the root of disk c. Now I change my module so that now, the file block resembles this :
    [file ('d:/generated/'.concat(class.name).concat('.c'), false, class.id)]

    The class itself hasn't changed one bit; so both the file name (class.c) and its id (class.id) remain constant. How can the tool find back that a file has already been generated for such an ID?

    The tool itself cannot keep a reference to all files it has generated along with their IDs and locations; the possibility that we're generating files under version control and that others can generate the same on their own machines forbids this. The solution would then be to save the file along with its ID, thus breaking the WYSIWYG assumption of the specification as unwanted information would show up in the generated file.

    And even like that, the tool would need to lookup throughout the whole file system of the target in order to try and find a file which ID is the same as what we need to generate. With the current computers, that could mean searching within terabytes of data in order to find a file that might not even exist in the first place, and that for each [file] block of a generation module.

    I believe this unique ID is a good idea in theory, yet seeing as this idea cannot be implemented as more than an idea, I think all references to an ID should be removed from 7.3 (description of the file block), 8.1 (metamodel), 8.1.17 (file block's attributes) and 8.2 (concrete syntax).

  • Reported: MOFM2T 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

current version of the specification doesn't allow for any "post-processing" of the generated text.

  • Key: MOFM2T11-4
  • Legacy Issue Number: 14031
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    The current version of the specification doesn't allow for any "post-processing" of the generated text. I can see two potential needs of post-processing : 1) template level. As well as users can specify guards and overrides, They should be offered the possibility to specify a "post" action in the form of a template or operation call that would be executed on the whole generated text (except for those nested within [file] blocks, see point 2)). For example, I could be defining a template that generates the text pertaining to the body of a Java Class. I might want to trim this text from all surrounding whitespaces before generating and returning it. This would make something like (on UML Class) : [template public classBody(clazz : Class) post (trim())] ... [/template] Such a feature would allow for more readable templates as the user wouldn't be forced to trim() everywhere this template is used. 2) file level. Users might want to call something as a post-processing of a file generation. The most obvious example is the call for a code formatter after a code generation. As above, this would give something like : [file ('Class.java', false) post (format())/] ... [/file]

  • Reported: MOFM2T 1.0 — Thu, 25 Jun 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3, 8.1, 8.1.17

  • Key: MOFM2T11-3
  • Legacy Issue Number: 13997
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    MTL defines an "open mode" to define how file blocks should behave : whether they append to existing files or overwrite them is defined this way. These two modes are not sufficient : users might want to generate files only when they don't exist. This can be either the very first transformation they execute (thus the file doesn't exist and need be created) or a latter generation when the user has deleted (inadvertently or on purpose) the target file. This is useful for configuration files that do not accept comments (thus rendering protected blocks unusable as these need a marker). An example of such a file is java's MANIFEST.MF file which format is extremely rigid.

  • Reported: MOFM2T 1.0 — Wed, 17 Jun 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add an attribute to the files block for users to specify generated file's encoding

  • Key: MOFM2T11-7
  • Legacy Issue Number: 14437
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    MOFM2T aims at being a standard for code generation, and as such it will be used to generate/override files that are under a version control management system. Files can then be generated indiscriminately under windows, linux or mac ... or the three at once for 'big' development teams.

    The generated file's encoding then becomes an issue : we cannot always generate files with the default system's encoding : windows' CP1252 as no equivalent in unices, and unix' UTF-8 might cause problems in windows if windows developpers re-generated files that have been first generated under an unix system.

    File encoding should be an optional attribute of the file blocks; so someone could write
    [file ('class.java', false, 'UTF-16')] or [file ('class.java', false, 'ISO-8859-1')] to tell that the target file should be encoded in such or such way.

    Note : this goes along with a previously raised issue in which I asked that the file's unique ID be removed. we'll need to find how to describe the encoding if the unique ID is not removed (as that would make file blocks with two optionnal expressions as their last parameter).

  • Reported: MOFM2T 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos/issues in the examples

  • Key: MOFM2T11-6
  • Legacy Issue Number: 14436
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    Some of the examples given in the specification assume that there is a "+" operator defined between Strings. This is not true in OCL, and there is none defined in the MOFM2T specification itself.

    page 9, section 7.2 :
    [trace(c.id()+ '_definition') ]
    should be
    [trace(c.id().concat('_definition')) ]

    page 9, section 7.3 :
    [file (‘file:\\’+c.name+’.java’, false, c.id + ‘impl’)]
    should be
    [file (‘file:\\’.concat(c.name).concat(’.java’), false, c.id.concat(‘impl’))]

    Furthermore, the description of this examples tells readers that a file named "cust.sql"; this is wrong. the text below the example of 7.3 should be :

    ---------8<---------
    Suppose the above specification was run on a class named ‘cust,’ it would produce Java code in cust.java file and a log
    entry ‘processing cust’ in log.log file. Suppose after generation, the storage specification was added in the protected area
    of file cust.java. Even if the classname is changed later, say to ‘customer,’ a tool will be able to retain the storage
    specification in the new file customer.java as the file block takes unique id as a parameter that hasn’t changed (for ‘cust’
    object). The uri ‘stdout’ denotes the stdout output stream.
    --------->8---------

    Page 30, Annex A.3
    Counting the "+"<=>"concat" error only once, this example sports no less than 9 syntax errors. Replace all text with :

    ---------8<---------
    [module class_header_gen ( UML ) /]

    [template public class_header(c : Class)

    { Integer count = -1; }

    ]
    [file (c.name.concat('.cpp'), false)]
    [trace(c.id().concat('_header'))]
    // Bit vector #defines
    [for(a : Attribute | c.attribute)

    { Integer count = count + 1; }

    ]
    #define [a.name/]_BIT [count/]
    [/for]
    class [c.name/] [for(c:Class | c.super) before(':') separator(',')] [c.name/] [/for]
    {
    bool bitVector [‘[‘.concat(c.attribute->size()).concat(’]’)/];
    // Attribute declarations
    [for (a : Attribute | c.attribute)]
    [a.type.name/] [if(isComplexType(a.type))]*[/if] [a.name/];
    [/for]
    // Constructor
    [c.name/]()
    {
    // initialize bit vector
    for (int i = 0; i < [c.attribute->size()/]; i++)

    { bitVector[‘[i]’] = 0; }

    [protected ('user_code')]
    // your code here
    [/protected]
    }
    // Attribute set/get/isSpecified methods
    [for (a : Attribute | c.attribute)]
    void Set[a.name/] ([a.type.name/] [if(isComplexType(a.type))] * [/if] p[a.name/])

    { bitVector[’[‘.concat(a.name).concat(’_BIT]’)] = 1; [a.name/] = p[a.name/]; }

    [a.type.name/] Get[a.name/] ()

    {return [a.name/];}

    bool isSpecified[a.name/]()

    {return bitVector[’[‘.concat(a.name).concat(’_BIT]’)];}

    [/for]
    // Method declarations
    [for (o : Operation | c.operation) ]
    [o.type.name/] [o.name/] ([for(p:Parameter | o.parameter) separator(',')] [p.type/] [p.name/] [/for]);
    [/for]
    }
    [/trace]
    [/file]
    [/template]
    --------->8---------

    Another solution to fix these errors would be to rely on the 2.1 version of the OCL specification which will introduce a '+' operator for Strings; or to add this operator in the MOFM2T specification.

  • Reported: MOFM2T 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

WG: Attribute accessors and mutators

  • Key: MOF14-81
  • Legacy Issue Number: 2876
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) Should the describe() and modify() operation available be on instance and
    class level interfaces? For class level attributes it is not necessarly
    needed because they probably will not be read and modified very often in a
    group.

    2) The property set should be defined in a value-struct. Which attributes
    should the instance level value-struct contain? class level and instance
    level attributes. I would prefer only to have instance level attributes in
    the instance level modify() and describe() operations because of (hopefully)
    the separation of instance and class level interfaces (no inheritance
    anymore!).

    3) Should the value-struct also contain multi-valued attributes. I would
    prefer, not to include multi-valued attributes in the value-struct because
    of the modify() operation.

    4) How about read-only attributes. If the same value-struct is used for
    describe() and modify(), should the read-only attributes be included in the
    value-struct and ignored in the modify() operation?

    5) To define the value-struct as a NamedValue sequence with the values of
    the type any (as available in the Reflective interface) is not optimal
    because this operation is untyped and requires the use of the any type. The
    value-struct should be typed.

    6) In our work we have defined the value-struct, modify() and describe()
    operations as model-specific operations (this is fully MOF-compliant). This
    allows us to customize the value-struct as needed. However, because probably
    everybody has the same requirements there should be a way in the MOF-spec to
    defined such constructs in a standard way.

  • Reported: MOF 1.2 — Thu, 9 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof rtf issue - coverage of RefXXX interfaces by MOF metamodel

  • Key: MOF14-83
  • Legacy Issue Number: 2925
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    This issue is to ensure that the MOF metamodel contains sufficient information
    to hold information available through the RefObject and related interfaces.
    Examples include the metaObject-instances relationship.

    XMI documents using the MOF DTD should include sufficient information to be used
    as backup/restore and initialization of a MOF-compatible system. The MOF
    interfaces should be complete enough to enable this capability.

  • Reported: MOF 1.2 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof rtf issue - setting UUIDs

  • Key: MOF14-82
  • Legacy Issue Number: 2923
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    The MOF interfaces need to provide an API to set uuids. A convention for
    denoting uuids for metamodel objects defined by OMG standards would be
    beneficial. For example, the uuids of the UML Class, Attribute, and Operation
    constructs could be set following this convention by the UML RTF.

  • Reported: MOF 1.2 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tags that parameterize a meta-model mapping

  • Key: MOF14-66
  • Legacy Issue Number: 2165
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Summary: If we allow Tags to parameterize a meta-model (e.g. IDL) mapping
    as proposed for issue 1307 (for example), there needs to be a reliable
    way for a client of the mapped interfaces to find that Tags that were
    in force. Without this, it cannot reflectively work out what the mapped
    interfaces do.

    Additional text:

  • Reported: MOF 1.2 — Wed, 4 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is a UML "profile"?

  • Key: MOF14-65
  • Legacy Issue Number: 2046
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The concept of profile may need to be escalated to the MOF level (for
    example as a subset of metadata constructs packaged together with
    appropriate classifiers, tags, constraints etc. -). I agree that
    creating new metamodels for each minor extension is not a tractable
    solution to the problem - especially if it means tool vendor cost of
    supporting it is too much.

  • Reported: MOF 1.2 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF RTF Isue: Conflict between "Facility" and "Package Object "

  • Key: MOF14-62
  • Legacy Issue Number: 1505
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a major conflict between the "Facility" Package
    described in Section 4 and the M1-level object model expressed in
    Section 7. Section 4 defines a concept of a "model repository",
    embodied by the Facility::ModelRepository class, as the boundary for
    M1-level associations and classifier level state. Indeed, this seems
    to be the main purpose of Facility::ModelRepository instances. On the
    other hand, the IDL mapping in Section 7 defines the M1-level
    <package-name>Package interface with the primary purpose of providing
    this boundary. [Section 5 is ambiguous.] This overlap in purpose and
    functionality is causing confusion, and is obscuring the need for
    standardisation of something to provide a container and a directory
    for a set of (possibly unrelated) models and meta-models.

  • Reported: MOF 1.2 — Fri, 5 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Generated operations returning attributes/references should not raise Cons

  • Key: MOF14-61
  • Legacy Issue Number: 1082
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The generated IDL for the MOF includes ConstraintError in
    the raises clause of operations generated via the Attribute
    Template and Reference Template, although these templates do
    not include spcification of that exception (identified in a
    separate issue). When that specification is updated, it
    should specify that the generated "read" operations do not
    raise this exception. The current IDL has ConstraintError
    in the raises clause of the following operations, which do
    not change the state of the model:

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of Reference "set" onto an ordered Association.

  • Key: MOF14-64
  • Legacy Issue Number: 1804
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The description of the semantics of Reference operations
    in section 6.2.2.1 needs to be extended to cover the multi-value
    update operations; i.e. "set" and "unset" when the referenced
    AssociationEnd is multi-valued. In particular, the semantics when
    either of the AssociationEnds is ordered need to be spelled out.

  • Reported: MOF 1.2 — Thu, 13 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ModelElement needs to have permanent, unique, unchanging, identifier

  • Key: MOF14-63
  • Legacy Issue Number: 1540
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ModelElement needs to have a permanent, unique, unchanging,
    non-redundant (within the transitive closure of a "large" namespace)
    (meta)identifier in addition to or as a replacement for qualifiedName
    as a local (meta)attribute.

  • Reported: MOF 1.2 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide tools to chapter 5 UML 1.3R9 draft

  • Key: MOF14-78
  • Legacy Issue Number: 2449
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I would like to suggest that the UML model interface defined by Chapter 5 of the
    UML1.3R9 draft provide tools the ability to register for notification of changes to the
    model contents in a manner consistent with the Observer pattern.

    This would provide a better mechanism for tool integration around a common
    model respository, allowing each tool in a tool suite containing tools developed
    by different vendors to present its own up to date "view" of the underlying model in
    a simple fashion.

  • Reported: MOF 1.2 — Thu, 11 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should Reflective.DesignatorType be "string"?

  • Key: MOF14-77
  • Legacy Issue Number: 2224
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Reflective interfaces currently use object references to
    "designate" the feature (etc) to which a reflective operation applies.
    In practice, I am finding that this is inconvenient for clients of the
    API and potentially difficult for implementations. I suggest that we
    reconsider the alternative; i.e. designating features using CORBA
    strings.

  • Reported: MOF 1.2 — Thu, 19 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do non-public Attributes need initialising?

  • Key: MOF14-80
  • Legacy Issue Number: 2839
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clearly stated in Section 5.8.9 whether or not a Class"e
    "create_<classname>" operation should have parameters to provide initial
    values for Attributes whose visibility is "protected_vis" or "private_vis".
    The same applies for 5.8.3 for classifier-level Attributes in the Package
    factory interface.

  • Reported: MOF 1.2 — Thu, 12 Aug 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL for Reflective Package Interfaces can conflict

  • Key: MOF14-79
  • Legacy Issue Number: 2527
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for the Reflective Package interfaces can conflict with IDL generated according to the MOF Model to IDL mapping rules. For example, when generating IDL for the UML metamodel, the UML class called Instance causes generation of an operation called create_instance which conflicts with the Reflective create_instance. The reflective interfaces should be changed to avoid such conflicts.

  • Reported: MOF 1.2 — Thu, 11 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify the semantics of Constraint verification

  • Key: MOF14-72
  • Legacy Issue Number: 2181
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: We need a thorough specification of the semantics of Constraint
    verification. This should cover the following:
    1) What happens; e.g. is the verification allowed to give up on the
    first error?
    2) When evaluation of deferrable Contraints can occur; i.e. where could
    the ConstraintError exceptions be raised?
    3) How evaluation of deferred Constraints is triggered.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add appropriate Attribute default values to the MOF Model

  • Key: MOF14-71
  • Legacy Issue Number: 2179
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Assuming that we add the capability of defining defaults for
    Attributes [see previous issue], there are a number of Attributes in
    the MOF Model that could / should have default values; for example
    "visibility" should default to "public", and "is_root"/"is_leaf" should
    default to "dont_care".

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF Model IDL versus OMG Style guidelines

  • Key: MOF14-76
  • Legacy Issue Number: 2188
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been pointed out to me that the MOF IDL doesn"t
    conform with the OMG style guidelines and conventions in two
    respects. First, there is no "#pragma prefix "org.omg"" in any of
    the core IDL files. Second, there is a convention that the
    outermost module names for OMG specs have a standard prefix
    depending on its "positioning" in the OMA; e.g. Cos, Cf or
    whatever.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need for light-weight References

  • Key: MOF14-75
  • Legacy Issue Number: 2186
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A requirement possibly exists for a light-weight version of
    References (or something like them), which at the M1 level does not
    require the existence of Attribute instance objects and the associated
    heavy weight querying mechanisms.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add a new technical overview chapter between chapters 2 and 3"

  • Key: MOF14-74
  • Legacy Issue Number: 2183
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The MOF specification needs a technical overview before chapter
    3 to help the reader put the details in the rest of the MOF specification
    into a perspective.

    Additional text:

    I am in the process of drafting a possible overview chapter.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Freezing mechanism for all models

  • Key: MOF14-73
  • Legacy Issue Number: 2182
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The MOF Model currently has a mechanism for freezing meta-models.
    It is underspecified, but the intent is that under certain conditions you
    can atomically freeze a valid meta-model. This issue proposes that this
    mechanism be re-specified so that it is available for all models.

    Additional text:

    Arguably this is an extension rather than an RTF issue.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add support for Exception generalization

  • Key: MOF14-69
  • Legacy Issue Number: 2177
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: UML currently supports Exception hierarchies, as do many
    object orient programming languages. MOF"s lack of support for this
    is perceived to be a limitation and an impediment to its use as a
    middleware independent meta-data framework.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Validate the OCL constraints in the MOF specification

  • Key: MOF14-67
  • Legacy Issue Number: 2173
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Take steps to validate as much as possible of the OCL in the
    MOF specification. Ideally, they should all be compiled and "executed"
    to ensure that they behave as expected. This should be feasible at least
    for the OCL constraints in the Model package.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add support for default values to MofAttribute

  • Key: MOF14-68
  • Legacy Issue Number: 2174
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been suggested that Model should be extended to allow
    attributes to specified to have default values. Default values can be
    defined in the MOF Model by adding an attribute of type "any" to
    MofAttribute. [Default expressions are too hard.]

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Define a MOF Class that is the supertype of all Classes

  • Key: MOF14-70
  • Legacy Issue Number: 2178
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Define a MOF Class that is the supertype of all Classes.
    It could be represented as a single-valued subclass of Model::Class.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

"exposedEnd" for any of the references in the MOF metamodel.

  • Key: MOF14-35
  • Legacy Issue Number: 4798
  • Status: open  
  • Source: Anonymous
  • Summary:

    If Attribute.isDerived was moved up to StructuralFeature, then you could model derived references. An example of such a derived reference in the MOF meta-model is Reference.exposedEnd, which is equivalent to ref.referencedEnd.otherEnd().

    Relatedly, the copy of ptc/2001-10-05 found on the RTF website doesn't include the "exposedEnd" for any of the references in the MOF metamodel.

  • Reported: MOF 1.4 — Fri, 21 Dec 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association Generalization Proposal

  • Key: MOF14-34
  • Legacy Issue Number: 4720
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    Here is a detailed proposal for adding association generalization to MOF
    1.5. This proposal does not address reference redefinition or overriding.
    I hope this proposal provides sufficient detail so that Steve Crawley can
    make changes to the specification. Please send your comments.

    Regards,
    Don

    Changes to Model

    Remove constraints [C-34] AssociationsHaveNoSupertypes, [C-35]
    AssociationMustBeRootAndLeaf, and [C-36] AssociationsCannotBeAbstract.

    Add a nonabstract association from AssociationEnd to AssociationEnd called
    RedefinesEnd. One end is called redefinedEnd, has a reference by the same
    name, and has multiplicity *. The other end is called redefiningEnd, has no
    reference, and has multiplicity *. This association is used to correlate an
    end with its corresponding end in a supertype association.

    Add new constraint: SupertypeEndsAreRedefined
    Evaluation policy: Deferred.
    Description: An end redefines each supertype's end.
    Context Association
    Inv: self.supertypes.contents->select(gc | gc.oclIsTypeOf(AssociationEnd))->
    forAll(ge : AssociationEnd |
    self.contents->select(sc |
    sc.oclIsTypeOf(AssociationEnd))->
    forAll(se : AssociationEnd | se.redefinedEnd->exists(re | re =
    ge)
    and se.otherEnd.redefinedEnd->exists(ore | ore =
    ge.otherEnd)))

    Add new constraint: RedefinedEndBelongsToSupertype
    Evaluation policy: Immediate.
    Description: Each redefinedEnd belongs to a supertype.
    Context AssociationEnd
    Inv: self.container.oclAsType(Association).supertypes.contents->
    includesAll(self.redefinedEnd)

    By the way, I noticed a bug. [C-38] AssociationsMustBeBinary is an
    immediate constraint, but it should be deferred. Otherwise, there is no
    valid way to create an Association.

    Changes to Abstract Mapping

    Add the following to Core Association Semantics.

    A link cannot be directly created for an Association with isAbstract set to
    true, but can be added indirectly as a link of a subtype association.

    Where a generalization exists between two associations, each link of the
    subtype association is logically a link of the supertype association - for
    each subtype Link <a, b> there implicitly exists a supertype Link <a, b> (or
    <b, a> depending on which subtype end redefines which supertype end).

    Removing a link from a Link_Set causes the logical link to be removed from
    each subtype association's Link_Set. Removing a link from a Link_Set also
    causes the logical link to be removed from each supertype association's
    Link_Set where the logical link is not otherwise present in the supertype
    Link_Set based on either having been put explicitly into the supertype
    Link_Set (where not abstract) or on being a link of some other subtype of
    the supertype. The net effect is that a Link_Set is a union of links put
    explicitly into the Link_Set with the Link_Sets of all subtypes.

    Changes to IDL Mapping

    In the template for associations, no add or modify operations are generated
    for an abstract association.

    In the template for references, no set, add, or modify operations are
    generated for an abstract association.

    Operations on RefObject for setting, adding, and modifying, and operations
    on RefAssociation for adding and modifying raise a new MofError, "Abstract
    Association", for creating a link of an abstract association.

    Changes to JMI

    In the template for associations, no add operation is generated for an
    abstract association.

    In the template for references, no set operation is generated for an
    abstract association. Also, the add and set operations on a reference
    collection throws a new JmiException, "AbstractAssociation", for an abstract
    association.

    For the reflective JMI interfaces, JmiException "AbstractAssociation" is
    thrown for refAddLink on an abstract association and for refSetValue on a
    reference on an abstract association.

  • Reported: MOF 1.4 — Fri, 30 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unnecessary constraint on import by nested packages

  • Key: MOF14-33
  • Legacy Issue Number: 4715
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Section 2.3.6.2 and Constraint [C-48] prevent a nested package from
    importing from anything else. This seems unnecessarily restrictive and makes
    the use practical of nested packages unlikely.

  • Reported: MOF 1.4 — Tue, 27 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong

  • Key: MOF14-31
  • Legacy Issue Number: 4664
  • Status: open  
  • Source: Anonymous
  • Summary:

    in section 5.8.12 "Reference Template", 1st para, it is stated: "The IDL generated for a Reference is declared within the scope of <ClassName>CLASS interface definition.", while the next para says: "The Reference Template defines the IDL generation rules for References. It declares operations on the INSTANCE interface to query and update links in the Association object for the current extent."

    I think, that all reference related IDL operations should go into the Instance interface, and not into the class proxy interface. This view is also compliant with 5.8.8 "Instance Template", that para states explicitly that the reference template is to be applied in the context of the instance template.

    Proposed Resolution:
    ====================
    Change the 1st para of 5.8.12 to "The IDL generated for a Reference is declared within the scope of <ClassName> interface definition.

  • Reported: MOF 1.4 — Tue, 6 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Restrictions needed for nested Packages and Classes

  • Key: MOF14-30
  • Legacy Issue Number: 4622
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In recent MOF RTF telcon discussions, we tentatively concluded that we need
    Constraints on the MOF Model to forbid 1) clustering of nested Packages,
    2) inheritance of nested Packages and 3) clustering of Classes.

    Additional Text:

    There are three arguments for the proposed restrictions. The first
    argument is that supporting inheritance / clustering in these cases adds
    to the complexity of MOF implementations. Since practical metamodels
    never seem to use these combinations of features, it is hard justify
    supporting them.

    The second argument is that clustering and inheritance of nested
    Packages is problematical. The elements of a nested Package are
    implicitly defined in the context of the nested Package's outer Package.
    A Constraint or Operation defined on / within a nested Package may
    reasonably refer to Associations or "all_of_*" collections in the
    enclosing context. When a nested Package is inherited or clustered
    outside of the context of its parent Package, the Constraint and
    Operation semantics may cease to be meaningful.

    The second argument does not apply to a nested Package that is
    inherited by another nested Package with the same outermost Package.
    However, we have not been able to identify a use case for this sort
    of thing. Hence the first argument applies.

    The third argument is that the MOF IDL mapping explicitly excludes all
    of these cases; see "Section 5.5 - Preconditions for IDL Generation".

  • Reported: MOF 1.4 — Thu, 18 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Looking up metaobject using MOFID

  • Key: MOF14-28
  • Legacy Issue Number: 4609
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    MOF should have a support for looking up metaobjects by MOFIDs (e.g. by adding getObjectByMOFID method to RefPackage interface).

  • Reported: MOF 1.4 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

resolveQualifiedName operation

  • Key: MOF14-27
  • Legacy Issue Number: 4607
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    I think it would be much more convenient to have resolveQualifiedName as a
    "classifier_level" operation on ModelElement instead of "instance_level"
    operation on Namespace. Now each time I want to resolve some object using
    its qualified name, I have to find all outermost packages (which is quite
    slow, because currently there is no better way of doing it than just iterate
    through all package instances and check whether they are outermost), then
    choose a package with a specified name and call resolveQualifiedName on that
    package passing rest of the qualified name as a parameter. This is much more
    complicated for users than it should be.

  • Reported: MOF 1.4 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deprecate object inheritance of class proxy interface

  • Key: MOF14-25
  • Legacy Issue Number: 4593
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    MOF should deprecate the use of factory/finder operations on object
    instances (i.e. the fact that generated instances inherit not only from
    their model superclass but from their class proxy). The main reason for this
    is that it does not separate concerns (why should an instance know about
    creating other instances or finding the population of the class?) and is not
    consistent with JMI.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alignment of reflective interfaces with JMI

  • Key: MOF14-24
  • Legacy Issue Number: 4592
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    MOF should consider aligning its reflective interfaces with JMI
    (specifically split some of RefObject into RefClass and common superclass
    RefFeatured). As well as the benefit of consistency it makes the interfaces
    more intuitive/comprehensible and typesafe.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigability of assoc. ends in MOF model

  • Key: MOF14-29
  • Legacy Issue Number: 4621
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    When I was looking at the current MOF 1.4 spec I could not find a place
    where is specified, which assoc. ends are navigable and which are not.
    There is an inconsistency between the UML picture of MOF metamodel and XMI
    (and IDL). Where the picture indicates that some ends (like
    RefersTo.referent) are not navigable, XMI says that they are navigable and
    also IDL contains getter method for these ends. So I guess the picture is
    wrong. This should be fixed, because it is in fact the only place where the
    users of the spec can see the navigability without looking at the
    hard-to-read XML file or generated IDL. It would be also helpful to add this
    also to the description of particular associations in section 3.5.

  • Reported: MOF 1.4 — Wed, 17 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove obsolete material

  • Key: MOF14-26
  • Legacy Issue Number: 4594
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The document needs a big revamp - e.g. a lot of the ancient pre-UML intro
    stuff. We
    should bear in mind that a lot of people will be coming to the spec/OMG
    cold as a result of JMI takeup and we should make the document as clean,
    lean
    and approachable as we can.
    It will be at least a year before MOF 2.0 reaches a stable/official state so
    I feel we should not wait.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tracking identity of replicated / interchanged metadata

  • Key: MOF14-23
  • Legacy Issue Number: 4586
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    When metadata is copied from one repository to another, or saved as an
    XMI document, it can be necessary to know if the physically distinct
    copies of the metadata are logically the same or logically different.
    There need to be mechanisms for testing whether copies are logically the
    same or different that work in all cases, not just within the context of
    a single repository.

  • Reported: MOF 1.4 — Wed, 3 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity be optional for non-navigable association ends.

  • Key: MOF14-32
  • Legacy Issue Number: 4700
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    If an association end is not navigable, specification of its
    Multiplicity should not be required. There is no practical use for this
    information and it does not make sense to require information that is not
    used.

    Proposed Resolution: Make Multiplicity optional in the MOF model.

  • Reported: MOF 1.4 — Mon, 12 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Metadata architecture needs to move away from the 4 levels and labels

  • Key: MOF14-10
  • Legacy Issue Number: 4111
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The Metadata architecture needs to move away from the 4 levels and labels: and refer to them as an example for straightforward cases such as database modeling. Other non 4-layer examples are also needed. While the MOF spec does point out that "M1-level and M2-level are relative labels", in practice the labels are applied quite rigidly and this positively causes confusion, sterile arguments, and in some cases harm to specifications as people grapple with whether a class belongs to M1 or M2 and if the former then it should be excluded "since the RFP asks for a M2 model". An example of the problems can be found in section 13.2 of the SPE joint submission (adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML not MOF. This will not change the MOF spec but how it is applied and models developed hence the severity of 'significant'.

  • Reported: MOF 1.3 — Fri, 8 Dec 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify XMI parameters for the MOF / XMI interchange format

  • Key: MOF14-9
  • Legacy Issue Number: 3897
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The MOF spec standardises an XMI-generated interchange format for MOF
    meta-models. The MOF spec includes the "input" MOF meta-model for the
    Model. It should also include a formal statement of the other XMI
    "parameters" used to generate the meta-model interchange format.

  • Reported: MOF 1.3 — Fri, 22 Sep 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Delete all non-MOF-specific terms from the Glossary

  • Key: MOF14-19
  • Legacy Issue Number: 4484
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Delete all non-MOF-specific terms from the Glossary. People have trouble enough with MOF terms and it's sensible to have one place to collect them all, without clogging them up with a load of irrelevant UML terms (e.g. action sequence). Plus it create a management issue of having to keep up with UML (which it has failed to already - not even including something as fundamental as 'Profile').

  • Reported: MOF 1.3 — Sun, 12 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add 'semantics' attribute to Operation.

  • Key: MOF14-18
  • Legacy Issue Number: 4483
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    At the moment MOF has no way to describe the behavior of an operation. A new attribute, 'semantics', String (0..1) should be added to Operation. A more sophisticated alternative would be to include a 'language' attribute also, as for Constraint. This would be somewhat restrictive in permitting only one coding of the semantics (e.g. not both OCL and Java). Better would be to use just one multivalued attribute of type StructuredDataType 'Expression'. This would be as in UML and have StructureFields 'language' (String 0..1) and 'body' (String 1..1). It begs the question as to whether this datatype should then be used in Constraint instead of the current 'language' and 'expression' attributes.

  • Reported: MOF 1.3 — Sun, 12 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The current MOF package level import is not sufficient

  • Key: MOF14-16
  • Legacy Issue Number: 4383
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The current MOF package level import is not sufficient. For instance, if a
    user wants to reuse "Boolean" from UML 1.4 Datatypes package, then she can
    only indicate "Datatypes" in MOF now. What is needed is that the user can
    say "Datatypes::Boolean" as a dependency. It would be counter-productive to
    create 12 subpackages of Datatypes and put each datatype in its own Package,
    just because it would let people reuse individual datatypes (without
    changing the MOF import rule).

  • Reported: MOF 1.3 — Wed, 20 Jun 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF-RTF issue: AttachesTo.modelElement - ordered

  • Key: MOF14-15
  • Legacy Issue Number: 4267
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    The modelElement end of AttachesTo association should be ordered. It does
    make sense to have one tag attached to several model elements in a specified
    order. (E.g. tag decorating a set of class attributes which create a unique
    identifier of instances of this class)

  • Reported: MOF 1.3 — Wed, 11 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof-rtf issue: Association Generalization

  • Key: MOF14-22
  • Legacy Issue Number: 4584
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    The MOF model should allow generalization of associations. It is often
    useful to have a more general root association and create several
    specializations for it (e.g. dependency and several kinds of dependencies as
    its subclasses).

  • Reported: MOF 1.4 — Mon, 1 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modeling OCL Helper Functions

  • Key: MOF14-21
  • Legacy Issue Number: 4569
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Many metamodels including the MOF Model (see 3.9.6) have 'OCL Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' model (e.g. to be represented in IDL).

    There seems to be no way of representing these in the MOF Model: and indeed the OCL Helper functions in MOF Specification do not appear in the XMI file, making it somewhat incomplete as a normative definition and meaning that many of the OCL constraints could not be executed by an OCL engine.

    This applies not only to MOF but to other metamodels.

  • Reported: MOF 1.4 — Sun, 16 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The role name of the Namespace->ModelElement association end

  • Key: MOF14-13
  • Legacy Issue Number: 4238
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Title: The role name of the Namespace->ModelElement association end should
    be the same
    than the corresponding reference name.
    This role is named 'containedElement' while the reference is named
    'contents'.
    Even if this is legal, we should avoid this in the MOF model because it's
    error prone (in particular
    when we use the UML class diagram notation as a convenience for specifying
    MOF compliant
    metamodels).

  • Reported: MOF 1.3 — Tue, 27 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

role is named 'containedElement' while the reference is named 'contents'

  • Key: MOF14-12
  • Legacy Issue Number: 4232
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The role name of the Namespace->ModelElement association end should
    be the same
    than the corresponding reference name.
    This role is named 'containedElement' while the reference is named
    'contents'.
    Even if this is legal, we should avoid this in the MOF model because it's
    error prone (in particular
    when we use the UML class diagram notation as a convenience for specifying
    MOF compliant
    metamodels).

  • Reported: MOF 1.3 — Wed, 21 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Representation of constraints

  • Key: MOF14-20
  • Legacy Issue Number: 4568
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The MOF XMI file uses 'OCL' for the language of the constraints, whereas the last paragraph of section 3.9.2.1 says that 'MOF-OCL' should be used [due to the minor variations from UML's OCL which are enumerated in 3.9.3].

    The description of the Constraint class in 3.4.27 should refer to how constraints are expressed for the MOF Model itself in 3.9.3 (using MOF-OCL). Though it should not be mandatory to use MOF-OCL, user-defined metamodels have the same requirements for constraint expression as the MOF Model and so the variant and usage of OCL is just as appropriate and necessary. Indeed it would be a lot more sensible to pull 3.9.3 out into a separate section since it applies to constraints in any MOF metamodel not just the MOF Model. NB This also needs to be reflected in the UML Profile for MOF.

  • Reported: MOF 1.4 — Sun, 16 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

predefined tag for marking attributes to act as qualifier in classifier

  • Key: MOF14-11
  • Legacy Issue Number: 4231
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Need a predefined tag for marking attributes that will 'act as a
    qualifier' in a classifier.
    In a metamodelling tool it may be useful to derive automatically an object
    identifier from one
    or more relevant attributes of the classifier (for instance a 'name'
    attribute).
    Note: The attribute 'acting as a qualifier' is owned by the classifier not
    by an association.
    Suggestion: pre-define a Tag named 'actAsQualifier : Boolean' applicable to
    any attribute
    of a classifier.

  • Reported: MOF 1.3 — Wed, 21 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Disallow null instance values

  • Key: MOF14-17
  • Legacy Issue Number: 4419
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    It can be argued that there is no need to allow null as a valid value
    for a Class instance. The possibility of null means that mapped APIs
    need to be more complicated; e.g. the IDL "unset_*" operations. This
    issue proposes that 'null' should be disallowed, making Class instances
    consistent with DataType instances. The IDL mapping could also be
    simplified.

  • Reported: MOF 1.3 — Wed, 25 Jul 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF IDL rules to minimize network roundtrips

  • Key: MOF14-14
  • Legacy Issue Number: 4255
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Various people have complained that retrieving meta-data (typically
    features of Classes) using the IDL produced by the MOF IDL mapping
    involves too many round-trips. This is preventing people from using
    MOF generated IDL in projects. This issue calls for a solution (or
    solutions) to this problem.

  • Reported: MOF 1.3 — Fri, 6 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 Why prevent nonpublic Associations?

  • Key: MOF14-5
  • Legacy Issue Number: 3447
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, constraint C-37 requires Associations to be
    public. Support for nonpublic Associations is a valuable capability that
    should not be forbidden. In particular, when there are references on all
    navigable ends of an Association, the M1 Association object is fully
    redundant in the capabilities it provides. Making the Association private
    or protected eliminates the need to support redundant public interfaces for
    capabilities available most conveniently through references. The
    association is an important part of the model in that it defines the
    semantics and behavior of the references, but no public Association
    interface is needed. The IDL and other interfaces generated from metamodels
    is already too large. Constraint C-37 simply makes it larger than it needs
    to be.

    Note that the CWM submitters to OMG desire to use nonpublic associations
    extensively in CWM's 26 metamodels.

    Recommendation: Delete C-37.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 IDL template for clustering uses wrong name

  • Key: MOF14-4
  • Legacy Issue Number: 3445
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 specification, section 5.8.4, the use of
    "<clustered_package_name>_ref" (both in the template and as a subheading) is
    incorrect. It should be "<import_name>_ref". The Import name provides the
    alias for a clustered package within a clustering package. The Package name
    is used to identify the type of the M1 package object, not the IDL attribute
    name.

    Recommendation: change "<clustered_package_name>_ref" to
    "<import_name>_ref".

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Template should suppress add for [x..x] Attributes

  • Key: MOF14-2
  • Legacy Issue Number: 3112
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The Attribute template suppresses the "remove" operations for multi-valued
    Attributes whose lower and upper bounds are the same. [This makes sense
    because removing an element would always trigger an underflow error.] However,
    similar logic has not been applied to the "add" operation. We should consider
    suppressing "add" operations for multi-valued Attributes whose lower and upper
    bounds are the same, since the operation must always trigger an overflow error
    in this case.

  • Reported: MOF 1.3 — Mon, 13 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF and IDL repository ids

  • Key: MOF14-1
  • Legacy Issue Number: 3043
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The AB is insisting that altered IDL types (including types that reference
    > altered IDL types) be versioned by specifying a new repository id. This
    > presents special issues for generated IDL when a source model is revised
    > and the IDL regenerated.
    >
    > Recommendation
    >
    > For generated IDL the safest thing is probably to generate a new UUID-based
    > repository id for all generated IDL interfaces and generated IDL structs,
    > valuetypes, etc.

  • Reported: MOF 1.3 — Sat, 20 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reflective interface for Package factory

  • Key: MOF14-8
  • Legacy Issue Number: 3745
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is no reflective version of the Package factory interface. In
    retrospect, an abstract interface would be useful for generic package
    creation using Package specific factory objects, and a concrete interface
    would be useful for a "universal" Package factory object.

    Discussion:

    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.
    The previous outcome was to defer this to the MOF 2.0 RFP.

  • Reported: MOF 1.3 — Mon, 17 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor changes to some Reflective operations

  • Key: MOF14-7
  • Legacy Issue Number: 3744
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The RefAssociation ops that are parameterised by Link would be easier to
    use if parameterized by two RefObjects. The RefObject ops for
    add/modify/removing
    ele,emts of Attribute/Reference collections should be renamed; i.e. add_value
    becomes add_member. Other minor tweaks would make the interfaces easier to
    use.

    Discussion:

    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.
    The previous outcome was to defer this to the MOF 2.0 RFP.

  • Reported: MOF 1.3 — Mon, 17 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF specifies no interfaces for actually (de-)serializing a model

  • Key: MOF14-3
  • Legacy Issue Number: 3411
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    MOF specifies no interfaces for actually (de-)serializing a model (to, for example, a XMI stream). Without such an interface it is not possible to guarantee that 2 XMI tools/repositories can communicate with each other, regardless of how completely they support MOF/XMI. Since the OMG is meant to be about interoperability this is a critical omission.
    It would make sense for MOF to make use of the Streamable interface defined as part of the Externalization service.
    And for the capability to be defined against Namespace to allow reasonable flexibility of granularity.
    Obviously XMI is only one possible format for the stream: the XMI specification should also be extended to fit into the detailed specification adopted for streaming MOF-compliant metamodels.

  • Reported: MOF 1.3 — Mon, 13 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 Package should subtype Classifier

  • Key: MOF14-6
  • Legacy Issue Number: 3448
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, a Package is not a subtype of Classifier. But
    an M2 package does have M1 instances (package extent objects), and the M2
    Package defines the type of those M1 objects. Therefore, a Package really
    is a Classifier. It is a type. It can be thought of as a component type,
    and in that sense a Package should be able to contain behavioral features.
    Also, an attribute type that is a Package should be treated as a pointer to
    a package extent object.

    Recommendation: make Package a subtype of Classifier, or fold Classifier
    into GeneralizableElement.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT