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.

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)

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.