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

MOF merges the UML package into its Reflection package. The UML contains many packages, such as CommonStructure. The package merge defines that such packages are deep copied into the resulting package. All the packages of the UML are also imported into the UML package. Package merge just copies these import relationships. It doesn't merge the imported elements: UML 2.5: Imported elements are not merged (unless there is also a PackageMerge to the Package owning the imported element).

In effect, it means that MOF contains two unrelated element definitions: CommonStructure::Element and Reflection::Element. In fact all MOF elements are not merged with their UML counterparts.

In UML 2.4 all the packages were merged into the UML package. Therefore, all elements were directly contained in this package. Therefore, it was sufficient to merge it.

A possible solution: Create in MOF a package structure mirroring the UML packages.

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

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

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).

Any of the five files linked at https://www.omg.org/spec/MOF2RDF/1.0/#docs-normative-machine don't exist at the current URL.

Annex B (informative) provides convenience links to the executable OCL files that implement the EMOF and CMOF constraints (with respect to the shared metamodel for MOF Core and UML). The provided links are crossed:
The constraints for EMOF are in: http://www.omg.org/spec/MOF/20131001/CMOFConstraints.ocl The constraints for CMOF are in: http://www,omg.org.spec/MOF/20131001/EMOFConstraints.ocl

Also, the second link has a comma instead of a period between www and omg.

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

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

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.)

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"?).

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

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.

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?

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

The diagram on p6 includes URIStore but with incomplete lines.

There is no subsection for it in 6.2.

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?

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).

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?

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

1. The figures should have numbers and captions

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?

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

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

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.

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

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

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.

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?

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.

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.

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.

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

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.

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

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

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.

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

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.

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.

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

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

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.

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

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

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

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?

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()?

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?

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.

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

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)

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?)

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.

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

)/]
[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.

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)

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

]
#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.

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

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')]

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.

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]'

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]

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]

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

[Employee : Table]

V
[Department_fky : ForeignKey]

v
[Department_pky : Key]
^

[Department : Table]

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

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.

The "MOF Models to Text Transformation Language" specification has an implementation within Eclipse which is not listed on the document catalog ( http://www.omg.org/technology/documents/modeling_spec_catalog.htm ). The implementation name is Acceleo ( http://www.eclipse.org/modeling/m2t/?project=acceleo ), the name that should appear on the document catalog should probably be "Eclipse - Acceleo".

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).

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]

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.

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).

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)

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

]
#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++)

[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/])

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

bool isSpecified[a.name/]()

[/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.

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.

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.

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.

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:

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.]

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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'.

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.

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').

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.

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).

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)

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).

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.

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).

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).

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.