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

QVT 1.4 RTF — Open Issues

  • Key: QVT14
  • Issues Count: 68
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
QVT14-70 QVTo: new(a) typo QVT 1.3 open
QVT14-69 QVTo - Meaningless Stereotype qualifier QVT 1.3 open
QVT14-68 How are comments persisted? QVT 1.3 open
QVT14-67 Optional features must be handled in separate relations QVT 1.3 open
QVT14-66 QVTr: checkonly confusion QVT 1.3 open
QVT14-65 QVTr: Single argument RelationCallExp is not crazy QVT 1.3 open
QVT14-59 QVTr : Lack of clarity on use of top relations in where clauses QVT 1.3 open
QVT14-64 QVTr: Allow optional Object/CollectionTemplate clauses QVT 1.3 open
QVT14-63 QVTr: Eliminate Primitive Domains QVT 1.3 open
QVT14-62 QVTo: Conflicting shared Extent residence QVT 1.3 open
QVT14-61 Multiple Extents per TypedModel QVT 1.3 open
QVT14-60 QVTr : Missing multi-when/where invocation QVT 1.3 open
QVT14-55 QVTr - Check before enforce is unsound QVT 1.3 open
QVT14-56 QVTr: checkonly PropertyTemplateItems QVT 1.3 open
QVT14-58 QVTr: overriding create nothing QVT 1.3 open
QVT14-50 QVTr - how does a Key handle inheritance? QVT 1.3 open
QVT14-57 QVTr - Rel2Core is impractical QVT 1.3 open
QVT14-54 QVT - Copy semantics QVT 1.3 open
QVT14-53 QVTr - templated relations QVT 1.3 open
QVT14-16 QVTr: Declaration Order QVT 1.2 open
QVT14-6 QVTr: Rule Overriding semantics QVT 1.1 open
QVT14-52 QVTc - overrides/overidden are confusing QVT 1.3 open
QVT14-49 QVTo - log should not provoke exceptions QVT 1.3 open
QVT14-48 QVTr - multi-rooted primitive domain QVT 1.3 open
QVT14-47 QVTr - Fixed-point semantics QVT 1.3 open
QVT14-46 QVTc - Partial Assignment QVT 1.3 open
QVT14-33 QVTo : Missing % specification QVT 1.3 open
QVT14-45 QVTo - obscure % shorthand QVT 1.3 open
QVT14-44 QVTo - Confusing reference to modulo operator QVT 1.3 open
QVT14-37 [QVTr] Add CollectionTemplate comprehension content QVT 1.3 open
QVT14-43 QVTr - Ordered Collection Template semantics QVT 1.3 open
QVT14-42 QVTo: re-raising an exception QVT 1.3 open
QVT14-41 Stereotype transformation QVT 1.3 open
QVT14-40 QVTo: Inconsistent != / <> QVT 1.3 open
QVT14-39 QVTc/QVTr : (Guard)Variable is not an OCL Variable QVT 1.3 open
QVT14-38 QVTr - Missing UML2RDBMS application QVT 1.3 open
QVT14-36 QVTr : Redundant opposite notation QVT 1.3 open
QVT14-34 QVTo : use-traditional-comparison-sysntax typo QVT 1.3 open
QVT14-32 QVTo : Missing !-> specification QVT 1.3 open
QVT14-31 QVTo : Missing indexing disambiguation. QVT 1.3 open
QVT14-30 QVTo : Missing shorthands QVT 1.3 open
QVT14-25 QVTo : Confusing isVirtual definition for imperative operation calls MOF 1.2 open
QVT14-27 QVTo : Unclear isBlackbox attribute for libraries QVT 1.3 open
QVT14-28 QVTr : Missing Collection support QVT 1.3 open
QVT14-29 QVTo : Unclear collection test shorthand QVT 1.3 open
QVT14-26 QVTo: How is an inherited mapping traced QVT 1.3 open
QVT14-23 QVTo: How can an UnlinkExp.target be a Property QVT 1.2 open
QVT14-14 Rationalize title MOF 1.2 open
QVT14-15 Trace Record not suitable for Incremental Execution MOF 1.2 open
QVT14-20 QVTo: What are the operation overloading semantics? MOF 1.2 open
QVT14-21 QVTo: Late resolution is unuseable in multi-pass transformations QVT 1.2 open
QVT14-18 QVTo: Enhance Status to support access to nested transformation trace data MOF 1.2 open
QVT14-19 QVTo: Eliminate deprecated Typedef class MOF 1.2 open
QVT14-22 QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL MOF 1.2 open
QVT14-24 CLONE - current abstract syntax of ImperativeOCL introduces a couple of unclear situations QVT 1.0 open
QVT14-17 QVTr: Missing TracePackage QVT 1.2 open
QVT14-13 QVTo: Standard Library mode and namespace QVT 1.2 open
QVT14-12 QVTc/QVTr: Pattern.bindsTo composition QVT 1.2 open
QVT14-11 Inconsistent multiple inheritance QVT 1.1 open
QVT14-10 QVTr: working with stereotypes: QVT 1.0 open
QVT14-9 QVTo: Inadequate definition of "late" semantics QVT 1.2 open
QVT14-8 QVTo: Enhance ObjectExp to allow constructors invocation QVT 1.1 open
QVT14-5 QVTc/QVTr: View/Transformation discrepancy QVT 1.1 open
QVT14-4 QVTo: Relationship between QVTo Mapping and QVTr Relation QVT 1.1 open
QVT14-3 QVTr: syntax mapping (correction to Issue 10646 resolution) QVT 1.1 open
QVT14-2 QVTr: BlackBox operation signature difficulties QVT 1.0 open
QVT14-7 QVTr: Deletion semantics QVT 1.1 open
QVT14-1 QVTr: Undefined semantics QVT 1.0 open

Issues Descriptions

QVTo: new(a) typo

  • Key: QVT14-70
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.1.8 has

    column := self.attribute->new(a) Column(a.name,getSqlType(a.type));

    Surely the (a) is a typo?

  • Reported: QVT 1.3 — Wed, 27 Jul 2022 17:31 GMT
  • Updated: Wed, 27 Jul 2022 17:31 GMT

QVTo - Meaningless Stereotype qualifier

  • Key: QVT14-69
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.4.6 introduces a <<>> syntax with an example whereby <<id>> provides the UML isID identification. The syntax appears as part of a general <<IDENTIFIER,IDENTIFIER>> syntax so presumably there may be many idenientofioers not just the "id" special case. Surely the IDENTOFOER should at least be a qualified name to identify the package and surely "id" should be qualified to indicate that it is from a UML namespace and should be spelled in accordance with UML spelling?

  • Reported: QVT 1.3 — Sat, 6 Mar 2021 07:52 GMT
  • Updated: Sat, 6 Mar 2021 07:52 GMT

How are comments persisted?

  • Key: QVT14-68
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVT supports two styles of comment, single/multi-line each of which may precede/follow the commented syntax element. (A leading new-line distinguishes a preceding from a following comment).

    The QVT AS inherits a Comment element from MOF with body and annotatedElement properties. This is inadequate to distinguish the two styles or the two positions. Could be fixed by a couple of Boolean properties.

    Comments may also be applied to punctuation that has no corresponding model element.

    if x then y
    else // must have an else
    z endif

    Perhaps an annotatedText is necessary to allow a comment to refer to punctuation

    <comment multiline="false" prefix="false" annotatedText="else" body="must have an else"/>

    Might need an annotatedIndex too for the case where the annotatedText occurs multiple times.

    Since the annotatedElement is already there, it might be less klunky to anchor the markup with annotatedElement="...z..." precedingText="else", where "...z..." is the appropriate fragment to reference the z element.

  • Reported: QVT 1.3 — Fri, 9 Oct 2020 09:53 GMT
  • Updated: Fri, 9 Oct 2020 09:53 GMT

Optional features must be handled in separate relations

  • Key: QVT14-67
  • Status: open  
  • Source: King's College London ( Kevin Lano)
  • Summary:

    In the standard it is stated that all source variables of a relation must be bound, in order for the relation to be applied. This seems the only reasonable approach for relation application. However it has an interesting consequence in the case of *-multiplicity references r, or indeed for any reference r with multiplicity lower bound 0. The source domain in

    top relation R
    { checkonly domain src e : E { r = rx : R {}, att = attvalue };
    enforce domain trg f : F { rr = rrx : R1 {}, attf = attvalue };
    }

    will not match to an E instance x which has empty x.r, because rx cannot be bound to any element, and hence the relation R will not be applied to such x - and att will not be copied to attf.

    In other cases (non-empty x.r), instances of E are copied to instances of F, and a specifier could expect that R copies x : E with empty x.r to a y : F with empty y.rr, but because of the totality requirement on source bindings, no y is produced for such x.

    The QVT specification should alert specifiers to this issue, and that in such cases it would be necessary to split the above relation into two parts, one handling the mandatory features and other parts for each optional feature.
    Note that this issue does not arise in languages such as QVT-O and ATL where copying of optional features can be done 'all at once' rather than element-by-element.

  • Reported: QVT 1.3 — Sun, 10 Nov 2019 16:41 GMT
  • Updated: Mon, 11 Nov 2019 21:40 GMT

QVTr: checkonly confusion

  • Key: QVT14-66
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The descriptions regarding checkonly and enforce are incomplete and the examples are misleading.

    When a domain is selected as a target, there are three execution possibilities.

    • the target is enforced - created/replaced/updated/...
    • the target is checked - compared
    • the target selection is illegal - an unsupported direction

    The illegal state is never described, but is at the heart of a unidirectional transformation for which, as in RelToCore, the source-only domain has no checkonly/enforce and the target-only domain has enforce.

    In contrast almost all of the UML2RDBMS examples have the uml domain marked as checkonly, which requires that an execution from RDBMS to check a pre-existing UML is permissible. This requires that the transformation is genuinely bidirectional although by using checkonly rather than enforce the programmer has unhelpfully prohibited the to-UML result from being persisted.

    It is doubtful that checkonly has any value at all as a concrete syntax / abstract syntax annotation. Surely a plausible output domain is always enforce; it is the way in which the transformation is invoked that configures whether the enforce creates/replaces/updates/compares/checks... ? Perhaps it is the redundancy of checkonly that has led to the misunderstandings exemplified by the UML2RDBMS example that checkonly marks the input of a unidirectional relation.

    Actions required:

    • describe the third illegal target state
    • change UML2RDBMS examples to genuinely unidirectional
    • provide a bidirectional example
    • deprecate checkonly
  • Reported: QVT 1.3 — Mon, 14 Oct 2019 07:33 GMT
  • Updated: Mon, 14 Oct 2019 07:42 GMT

QVTr: Single argument RelationCallExp is not crazy

  • Key: QVT14-65
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In 7.11.3.8, RelationCallExp.argument has a lowerbound of 2 which seems sensible because surely any Relation must have at least an input and an output?

    No. A single output non-top Relation is useful to create a singleton output object independent of any input objects. Distinct when invocations can establish singleton ownership in one place and usage in many places.

    The lowerbound should therefore be 1.

  • Reported: QVT 1.3 — Thu, 27 Jun 2019 16:43 GMT
  • Updated: Thu, 27 Jun 2019 16:43 GMT

QVTr : Lack of clarity on use of top relations in where clauses

  • Key: QVT14-59
  • Status: open  
  • Source: King's College London ( Kevin Lano)
  • Summary:

    The QVTr specification does not clarify if top relations can be called from where clauses. It would seem to be a source of potential errors if top relations were both explicitly invoked from where clauses and implicitly invoked by the usual mechanism for top relations. An explicit call R(a,b) of a top relation would normally be redundant because R would be attempted on the source element a in any case through the normal mechanism.

    The clause should additionally state "Top level relations cannot be invoked from a where clause". As a consequence, primitive domains are only needed in non-top relations (clause 7.2.4 can state that primitive domains should only appear in non-top relations).

  • Reported: QVT 1.3 — Thu, 16 May 2019 10:40 GMT
  • Updated: Wed, 26 Jun 2019 14:28 GMT

QVTr: Allow optional Object/CollectionTemplate clauses

  • Key: QVT14-64
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    An <objectTemplate> may have an empty list of <propertyTemplate> but the surrounding {} are mandatory. Similarly a <collectionTemplate> may have an empty list of members but the surrounding {} are mandatory.

    It is common for patterns to refer to properties / members by type and often name without caring about nested properties / members, but because of the syntax the user must contend with a confusing syntax error until the {} are added.

    The user experience and patterns can be somewhat simpler if the {} can be omitted for empty content.

  • Reported: QVT 1.3 — Tue, 25 Jun 2019 08:08 GMT
  • Updated: Tue, 25 Jun 2019 08:08 GMT

QVTr: Eliminate Primitive Domains

  • Key: QVT14-63
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The fourth QVT14-59 comment identifies that Primitive Domain root variables are not useable.

    A top primitive domain input is only useful if the specification provides a mechanism to pass configuration to these inputs. It doesn't, so top primitive domains seem useless as is, and perhaps better supported by contextual properties.

    In https://bugs.eclipse.org/bugs/show_bug.cgi?id=548536 I thought a non-top primitive domain might be useful, but realized that the primitives were inputs in one direction and outputs in another violating the 7.2.4 restriction to inputs. Now that multiple root variables are permitted it seems that the primitive domain root variables should be moved to the appropriate domain so that they are directional. RelToCore does not use primitive domains. It appears that a genuine use case for a primitive domain with a root variable is lacking.

    Suggest: Replace the unfullied potential paramerization of top relations by immutable contextual trasformation properties in similar style to QVTo.

    Primitive domains are then reduced to the vague host domain of shared relation variables such as "name : String".

  • Reported: QVT 1.3 — Sat, 22 Jun 2019 08:24 GMT
  • Updated: Sat, 22 Jun 2019 08:24 GMT

QVTo: Conflicting shared Extent residence

  • Key: QVT14-62
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.1.3.2 says

    Each Extent for an in Model Parameter is immutable. It may be shared when the same external model is loaded by multiple in Model Parameters.

    8.1.3.4 says

    The roots of the forest have no containers, rather they are members of at most one Extent...

    Clearly the elements of a common sub-model loaded by/referenced for two distinct Model Parameters are shared, else there could be confusing duplicates. These elements are in multiple extents contradicting the "at most on".

    Suggest revise 8.1.3.4 to

    The roots of the forest have no containers, rather they are members of typically one Extent... A shared root may be a member of mutiple Extents.

  • Reported: QVT 1.3 — Thu, 6 Jun 2019 08:56 GMT
  • Updated: Thu, 6 Jun 2019 08:56 GMT

Multiple Extents per TypedModel

  • Key: QVT14-61
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVT13-26 requested support for collections of input models. This was resolved by generalizing the type of a ModelParameter to allow a Collection. This change was not necessary.

    If each input model has a distinct Extent, there need be no prohibition on the passing of multiple Extents to a single TypedModel. By default this will be treated as a multi-rooted model.

    In QVTr/QVTc where Extent is currently unused, reification of Extent as a transformable model element solves problems with providing a 'container' for multi-rooted models and allows collections of input/output models per TypedModel to be managed.

    In QVTo, Extent can be similarly reified but care is required to separate the similar functionality of Model as the/one-of-the TypedModel instances.

  • Reported: QVT 1.3 — Mon, 3 Jun 2019 09:25 GMT
  • Updated: Mon, 3 Jun 2019 09:25 GMT

QVTr : Missing multi-when/where invocation

  • Key: QVT14-60
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In QVTo the a paremnt mapping may pull its child mappings by e.g.

    result.children := self.children->map Child2Child();

    QVTr has no counterpart to this. It is needed by those pursuing a procedural style with where clause sequencing. Relations such as RVarSetToMBVarSet in RelToCore demonstrate the need for a multi-invocation.

    Since multi-directional usage prohibits the use of a result as in QVTo, suggest that a 1:1 relation invocation may be invoked to perform a N:N mapping by passing a collection where a non-collection was expected to at most one of the root variables of each domain.

  • Reported: QVT 1.3 — Fri, 17 May 2019 07:19 GMT
  • Updated: Fri, 17 May 2019 07:19 GMT

QVTr - Check before enforce is unsound

  • Key: QVT14-55
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVTr (and QVTc) defines check and enforce modes with a check-before-enforce specified to suppress a redundant enforce. This seems sensible but is only possible for trivial cases. A relation/mapping defines constraints between objects that check mode can validate. But while checking before enforcing none of the intermediate and trace objects exist, so only trivial relations/mappings whose intermediate objects can be inferred can actually be checked. In the general case most of an enforce execution must be performed in order to create the intermediates. In practice, much simpler to specify a full enforce to an internal-output that can then be synchronized with the output-under-test. Successful synchronization determines the check success. If an internal-output is still available as a consequence of an earlier enforce, then a synchronize and check of yet another output-under-test can re-use the enforce. But check cannot be done without a prior enforce. For the trivial cases implementations may synthesize an optimized enforce/synchronize to improve check performance.

  • Reported: QVT 1.3 — Mon, 31 Jul 2017 06:52 GMT
  • Updated: Sun, 12 May 2019 11:38 GMT

QVTr: checkonly PropertyTemplateItems

  • Key: QVT14-56
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Given an enforced pattern such as:

    a:A { b = b:B

    { c = c:C }

    }

    there is an ambiguity as to whether the target of a.b is to be enforced remotely and then re-used here (checked) or enforced locally, so it is enforced locally.

    This may perhaps be worked around using a Key, but the user must elaborate the pattern to redundantly define all the Key parts.

    This may be worked around using a when pattern that relates "b" to its enforcement elsewhere.

    Both the workarounds are tedious.

    It is possible that there is some smart related to containment relationships that can do better, but more likely it just adds confusion and requires deeper user insight.

    Suggest that remotely enforced PropertyTemplateItems can be annotated as checkonly to make the intent explicit.

    a:A { checkonly b = b:B

    { c = c:C }

    }

  • Reported: QVT 1.3 — Fri, 1 Sep 2017 08:26 GMT
  • Updated: Wed, 7 Nov 2018 09:37 GMT

QVTr: overriding create nothing

  • Key: QVT14-58
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    An overriding relation may need to create nothing when the derived input pattern does not need transformation by the polymorphism. It might be transformed elsewhere explicitly. (Concrete example is OclType in the ATL metamodel which is defined as a derived OclExpression in ATL but not in OCL.)

    Create nothing could be achieved by omitting the engforced domain but that violates a consistent overrideing domains WFR.

    Create nothing is more sensibly achieved by no output patterns in the enforced domain,

  • Reported: QVT 1.3 — Tue, 4 Sep 2018 10:57 GMT
  • Updated: Tue, 4 Sep 2018 10:57 GMT

QVTr - how does a Key handle inheritance?

  • Key: QVT14-50
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The semantics of Keys wrt to derived types is unspecified and as discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=512532 far from obvious.

    What are the WFRs for Keys?

    Are multiple keys per type allowed?

    Is key uniqueness applicable to derived types? or does each key have an implicit, distinct derived key for each derived and miltiply-derived type?

    Can a realized access of a Keyed variable return a differenr class that shares the same key?

  • Reported: QVT 1.3 — Sun, 26 Feb 2017 09:12 GMT
  • Updated: Fri, 9 Feb 2018 10:02 GMT

QVTr - Rel2Core is impractical

  • Key: QVT14-57
  • Status: open   Implementation work Blocked
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The soundness of QVTr relies on the fallacy that the Rel2Core transformation fully defines the QVTr semantics in terms of the fully defined QVTc semantics. The QVTc semantics are unfortunately not fully defined and the semantic errors in Rel2Core demonstrate that it can never have been exercised. When Rel2Core is consulted to determine the semantics of collection templates or relation overrides or .... oops. Missing.

    I have been trying to prototype a viable QVTr2QVTc as part of the Eclipse QVTd project and solved most of the problems, but...

    It is not sensible to transform a hierarchy of non-top overriding relations into QVTc since the need to partition each overriding relation into a pair of unfailing predicate matching and residual execution mappings is unreasonably hard using the very unhelpful ObjectTemplateExp+VariableExp+Variable pattern 'node's. A more sensible graphical PatternNode representation is necessary for readability and sanity.

    Suggest that a graphical QVTg representation be introduced so that QVTc and QVTr are defined by more realistic QVTc2QVTg and QVTr2QVTg transformations. Bypassing QVTc should avoid the need for QVTr2QVTc to provide an heroic workaround for every QVTc limitation.

    See https://bugs.eclipse.org/bugs/show_bug.cgi?id=529130 for more discussion.

  • Reported: QVT 1.3 — Fri, 22 Dec 2017 10:45 GMT
  • Updated: Fri, 22 Dec 2017 10:45 GMT

QVT - Copy semantics

  • Key: QVT14-54
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Model copy is a potentially well-defined behavior that can have a useful default implicit functionality.

    QVTr and QVTc have no copy.

    QVTo has a deep copy but since it is a library operation it is not part of the language and so it has no associated traceability. A first class copy is needed. See ICMT 2017: Christopher Gerking, David Schubert and Ingo Budde: Reducing the Verbosity of Imperative Model Refinements by using General-Purpose Language Facilities.

  • Reported: QVT 1.3 — Mon, 17 Jul 2017 20:55 GMT
  • Updated: Mon, 24 Jul 2017 16:01 GMT

QVTr - templated relations

  • Key: QVT14-53
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    UML supports templated types.
    OCL is aligned with UML.
    QVT extends OCL.
    Therefore QVT supports templated types possibly just through grammar inheritance.

    For relations, that have some similarities to operations, a template signature is required in order to allow a user to bind a specific enforced type. In the absence of templates, a relation defined on the template parameter lowerbound can only enforce the lowerbound.

  • Reported: QVT 1.3 — Tue, 20 Jun 2017 07:23 GMT
  • Updated: Tue, 20 Jun 2017 07:23 GMT

QVTr: Declaration Order

  • Key: QVT14-16
  • Legacy Issue Number: 19667
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVTr imposes an unnatural declaration order in the exposition of a RelationCS. Surely the when clause should be early and variable declarations where initializeable?

    Suggest relaxing the ordering constraint on declarations in a RelationCS to permit the more readable order

    • variable declarations used by when
    • when clauses
    • variable declarations used by check domains
    • check domains
    • variable declarations used by enforce domains
    • enforce domains
    • variable declarations used by where
    • where clauses
  • Reported: QVT 1.2 — Fri, 28 Nov 2014 05:00 GMT
  • Updated: Sat, 17 Jun 2017 08:08 GMT

QVTr: Rule Overriding semantics

  • Key: QVT14-6
  • Legacy Issue Number: 15417
  • Status: open  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The abstract syntax of QVTr allows a rule to be an override of another rule.

    Rule::overrides: Rule [0..1]
    The rule that this rule overrides.

    The concrete syntax of QVT allows it too:

    <relation> ::= ['top'] 'relation' <identifier>
    ['overrides' <identifier>]
    '

    {' .... '}

    '

    However, the only semantics I can see for 'overrides' is in clause 7.11.1.4 that says:

    "A rule may conditionally override another rule. The overriding rule is executed in place of the overridden rule when the overriding conditions are satisfied. The exact semantics of overriding are subclass specific. "

    Questions:

    1- What are the overriding conditions? are they implied or specified and if so how?

    2- I have not seen any other discussion of overriding in a subclass or Rule so not sure what is meant by "The exact semantics of overriding are subclass specific"?

    3- I have not seen any example of using 'overrides' what so ever in the spec, shouldn't there be one?

    4 - What is the semantics of overriding? is it related to inheritance in the OO sense ? I think QVTr needs a good "inheritance" model where you can relations can be called polymorphically.

  • Reported: QVT 1.1 — Fri, 13 Aug 2010 04:00 GMT
  • Updated: Sun, 21 May 2017 11:24 GMT

QVTc - overrides/overidden are confusing

  • Key: QVT14-52
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Rule::overrides specifies the Rule that this Rule overrides; no problem.

    The remote Rule is overridden by this rule.

    But the opposite of Rule::overrides is called overidden.Wrong way round, It should be called overriding. Rule::overriding navigates to the (many) Rules that override (not are overridden by) this Rule.

  • Reported: QVT 1.3 — Thu, 18 May 2017 17:13 GMT
  • Updated: Thu, 18 May 2017 17:32 GMT

QVTo - log should not provoke exceptions

  • Key: QVT14-49
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    If a variable has an invalid value and that variable is used by passing it to log(), it should not cause an assertion failure on the use of invalid.

  • Reported: QVT 1.3 — Mon, 20 Feb 2017 15:22 GMT
  • Updated: Mon, 20 Feb 2017 15:22 GMT

QVTr - multi-rooted primitive domain

  • Key: QVT14-48
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVT 1.3 removed the artificial restriction on 1 root variable per QVTr domain, but neglected to provide the elaboration for multiple roots per primitive domain. THis is needed to pass 2 parameters to a relation as is required by draft OWL <-> UML transformations.

    Suggest allowing a comma-separated list of roots.

  • Reported: QVT 1.3 — Sat, 11 Feb 2017 14:41 GMT
  • Updated: Sat, 11 Feb 2017 14:41 GMT

QVTr - Fixed-point semantics

  • Key: QVT14-47
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 18572 highlighted that QVT 1.1 seemed to require inconsistent fixed-point semantics. The resolution solved the inconsistency by requiring repeated execution to be external to QVT.

    However some transformations such as the TTC PetriNet to StateChart require repeated transforming.

    If QVTr supported the TypedModel::uses property then an endogeneous transformation whose input TypedModel uses its output TypedModel makes the repeated execution for fixed-point semantics consistent.

    Need to update 7.7/add a fixed-point semantics section.

    Need to add TypedModel::uses to the QVTr concrete syntax.

  • Reported: QVT 1.3 — Fri, 3 Feb 2017 18:28 GMT
  • Updated: Fri, 3 Feb 2017 18:28 GMT

QVTc - Partial Assignment

  • Key: QVT14-46
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    It is unclear how multiple mappings may conspire to populate the children property of a parent. Is the final truth of

    parent.children := aChild

    parent.children = Collection

    {aChild}

    or parent.children->includes(aChild)

    Suggest the latter, since the former can easily be programmed explicitly. This avoids the need to re-interpret a clarifying includes predicate as a partial assignment.

  • Reported: QVT 1.3 — Sat, 7 Jan 2017 14:03 GMT
  • Updated: Sat, 7 Jan 2017 16:24 GMT

QVTo : Missing % specification

  • Key: QVT14-33
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.4.7 defines a "%" mult_op but no accompanying specification.

    The disambiguation comment in 8.4.4 suggests a dual semantic, format half-specified, modulo is presumably Integer/UnlimitedNatural::mod

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 09:05 GMT
  • Updated: Mon, 19 Dec 2016 09:57 GMT

QVTo - obscure % shorthand

  • Key: QVT14-45
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.4.4 4 defines

    The notation “blabla %s\n” % myvar involving the binary '%' operator is a shortand for invoking the pre-defined 'format' operation.

    The inconsistent punctuation and lack of the longhand '"blabla %s\n".format(myvar)' makes for a hard read; which % is the shorthand?

    This really does not seem very useful. The textual saving is small, it only works for single argument formats, it introduces precedence challenges once the missing precedence is specified.

    (Eclipse QVTo does not implement the shorthand.)

    Suggest delete the shorthand.

  • Reported: QVT 1.3 — Mon, 19 Dec 2016 09:50 GMT
  • Updated: Mon, 19 Dec 2016 09:50 GMT

QVTo - Confusing reference to modulo operator

  • Key: QVT14-44
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The "The potential ambiguity with the modulo operator is solved thanks to the type of the first argument, which is a string in our case." text implies that either QVTo or OCL provides a modulo operator. OCL <= 2.4 does not. QVTo's grammar defines '% as a mult_op, perhaps just as the format shorthand, there are certainly no defined semantics such as what data types are applicable, how zero is accommodated.

    (Eclipse QVTo does not provide any % operator.)

    Suggest, delete the confusing sentence.

  • Reported: QVT 1.3 — Mon, 19 Dec 2016 09:38 GMT
  • Updated: Mon, 19 Dec 2016 09:38 GMT

[QVTr] Add CollectionTemplate comprehension content

  • Key: QVT14-37
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    ODM 1.0 uses a CollectionTemplate extension in which a collection comprehension is used to match Sequence content:

    checkonly domain uml assn : Association{general = superassn : Association{
    memberEnd = supSeq : Sequence(Property){usuper | true}},
    memberEnd = subSeq : Sequence(Property){uprop | true}}

    {supSeq->indexOf(usuper) = subSeq->indexOf(uprop)}

    ; // steps through both sequences in tandem

    It is not clear how to achieve this without a CollectionTemnplate iterator.

    The proposal for a co-iterator could avoid the guard and so allow

    checkonly domain uml assn : Association{general = superassn : Association{
    memberEnd = supSeq : Sequence(Property){usuper,index | true}},
    memberEnd = subSeq : Sequence(Property){uprop,index | true}};

  • Reported: QVT 1.3 — Fri, 22 Apr 2016 15:58 GMT
  • Updated: Sun, 4 Sep 2016 08:51 GMT

QVTr - Ordered Collection Template semantics

  • Key: QVT14-43
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    If a CollectIonTemplate is for an OrderedCollection e.g. in

    elements = oSet:OrderedSet

    {m1, m2 ++ rest}

    the literal could be ordered requiring m1 first, m2 next etc. But this inhibits the useful use case of iteration over the Collection unless we extend to:

    elements = oSet:OrderedSet

    {mBefore ++ m1, m2 ++ mAfter}

    Alternatively if 'Ordered' is just ignored, we create a disordered OrderedSet.

  • Reported: QVT 1.3 — Fri, 2 Sep 2016 14:00 GMT
  • Updated: Fri, 2 Sep 2016 14:12 GMT

QVTo: re-raising an exception

  • Key: QVT14-42
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The exception raising syntax is a bit of a mess, cherry-picking special syntaxes and thereby inhibiting general functionality such as raising a computed exception. It is therefore not possible to re-raise an exception.

  • Reported: QVT 1.3 — Wed, 15 Jun 2016 12:19 GMT
  • Updated: Wed, 15 Jun 2016 13:53 GMT

Stereotype transformation

  • Key: QVT14-41
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVTo has stereotypedBy and stereotypedStrictlyBy helpers and a * shortform to assist in the use of stereotypes, but seemingly only for read purposes.

    QVTc and QVTr have no overt support for stereotypes.

    Document why it isn't necessary.

    QVTo's myClass.stereotypedBy(MyStereotype) invocation is actually just the myClass.extension_MyStereotype <> null predicate. QVTc and QVTr can therefore support stereotypes using normal navigation. And as declarative transformation languages a stereotype navigation in the target domain is a stereotype assignment.

    QVTo should support stereotype assignment by:

    myClass.extension_MyStereotype := ...

    Just need an OclElement.allExtensions() helper to support reasoning on the actual steotypes without knowing which ones to 'poll'.

  • Reported: QVT 1.3 — Fri, 10 Jun 2016 09:54 GMT
  • Updated: Fri, 10 Jun 2016 09:54 GMT

QVTo: Inconsistent != / <>

  • Key: QVT14-40
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.4.4. bullet 6 says both available.

    Following bullet 8 it says only one or the other available.

  • Reported: QVT 1.3 — Fri, 10 Jun 2016 09:41 GMT
  • Updated: Fri, 10 Jun 2016 09:41 GMT

QVTc/QVTr : (Guard)Variable is not an OCL Variable

  • Key: QVT14-39
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    An OCL Variable requires its initializer to be statically type conformant to its type.

    A QVTc/QVTd (Guard)Variable defers conformance checking till run-time at which point a non-conformance is a predicate failure.

    There is therefore a problem with the WFR inherited from OCL.

    Suggest:

    VariableDeclaration should be the basis for Variable references.
    RealizedVariable should be a VariableDeclaration, not a Variable.
    GuardVariable should be a new derivation of VariableDeclaration.

    NB VariableDeclaration is the common supertype of Variable and Parameter, although VariableDeclaration is seriously underspecified by OCL.

  • Reported: QVT 1.3 — Sat, 14 May 2016 18:40 GMT
  • Updated: Sat, 14 May 2016 18:40 GMT

QVTr - Missing UML2RDBMS application

  • Key: QVT14-38
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The introduction to 10 concludes

    "and finally, the application of this transformation to the familiar object to relational transformation is shown to demonstrate the results"

    But the Section ends without this application. The QVTc variant of UML2RDBMS is not this application in a different place since the QVTc exposition does not follow the multi-unidirectional conversion style of RelToCore.

  • Reported: QVT 1.3 — Sun, 1 May 2016 09:32 GMT
  • Updated: Sun, 1 May 2016 09:32 GMT

QVTr : Redundant opposite notation

  • Key: QVT14-36
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVT 1.1 introduced an opposite syntax to support inverse navigation. e.g.
    in 7.3 "opposite(Class.attribute)".

    This is not needed since the OCL implicit opposite role name supports "Class" when there is no ambiguity, and "Class[attribute]" when an ambiguity needs resolution.

    The OCL syntax is shorter and reads forwards, unlike the redundant opposite syntax. Suggest deprecation.

  • Reported: QVT 1.3 — Fri, 15 Apr 2016 10:30 GMT
  • Updated: Fri, 15 Apr 2016 10:30 GMT

QVTo : use-traditional-comparison-sysntax typo

  • Key: QVT14-34
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.4.4 at the end has

    use-traditional-comparison-sysntax

    where surely

    use-traditional-comparison-syntax

    was intended.

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 09:06 GMT
  • Updated: Wed, 13 Apr 2016 09:06 GMT

QVTo : Missing !-> specification

  • Key: QVT14-32
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.4.7 defines a "!->" access_op but there is no accompanying specifucation.

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 08:40 GMT
  • Updated: Wed, 13 Apr 2016 08:40 GMT

QVTo : Missing indexing disambiguation.

  • Key: QVT14-31
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    OCL provides two under-specified semantics for the [] indexing operator

    qualifiedAssociationName[qualifierList]
    ambiguousAssociationName[oppositeAssociationName]

    QVTo introduces additional internally and externally ambiguous semantics without any disambiguation specification.

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 08:38 GMT
  • Updated: Wed, 13 Apr 2016 08:38 GMT

QVTo : Missing shorthands

  • Key: QVT14-30
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The following shorthands are missing from 8.4.5

    anExpression[aTypeExp]
    anExpression[anotherExpression]
    !
    !->

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 08:32 GMT
  • Updated: Wed, 13 Apr 2016 08:32 GMT

QVTo : Confusing isVirtual definition for imperative operation calls

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

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

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

QVTo : Unclear isBlackbox attribute for libraries

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

    An entire Module may be declared as blackbox using the isBlackbox attribute. Whereas it is obvious that a blackbox transformation consists of its signature only (name + model parameters) as it doesn't include any operations, what is a blackbox library? If it doesn't include operations as well, it is useless because it has no effective signature.

    If the isBlackbox attribute is useful for transformations only, should it be moved from Module to OperationalTransformation?

  • Reported: QVT 1.3 — Thu, 31 Mar 2016 09:30 GMT
  • Updated: Wed, 13 Apr 2016 08:19 GMT

QVTr : Missing Collection support

  • Key: QVT14-28
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The RelToCore transformation that 'defines' QVTr semantics has no semantics for Collections, either explicit through use of CollectionTemplateExp or implicit through use of Collection/non-Collection assignment conversion.

  • Reported: QVT 1.3 — Fri, 1 Apr 2016 06:15 GMT
  • Updated: Wed, 13 Apr 2016 08:19 GMT

QVTo : Unclear collection test shorthand

  • Key: QVT14-29
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.4.5 2 states "if a collection value is passed there is an implicit comparison with the size of the collection."

    This is clearly not the intent: no Collection can ever equal its size.

    Presumably the intent is to treat if (aCollection) as a shorthand for if (aCollection->notEmpty()).

    Suggest that all shorthands are spelled out explicitly in longhand.

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 08:18 GMT
  • Updated: Wed, 13 Apr 2016 08:19 GMT

QVTo: How is an inherited mapping traced

  • Key: QVT14-26
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVT 1.3 8.1.11.1 attempts to identify the hidden information that a trace record must contain. The text is not suitable for a multiple inheritance where there may be one invoked mapping and many executed mappings.

    Probably need to trace all executed mappings.

    Need to specify how the inherited mappings merge more clearly; probably as a section-wise merge.

    See https://bugs.eclipse.org/bugs/show_bug.cgi?id=489271.

  • Reported: QVT 1.3 — Wed, 9 Mar 2016 14:25 GMT
  • Updated: Wed, 9 Mar 2016 14:25 GMT

QVTo: How can an UnlinkExp.target be a Property

  • Key: QVT14-23
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The description of UnlinkExp.target specifies an OclExpression but describes a Property.

    Is this an error? Is it introducing a new PropertyLiteralExp?

  • Reported: QVT 1.2 — Wed, 21 Oct 2015 16:48 GMT
  • Updated: Tue, 22 Dec 2015 17:00 GMT

Rationalize title

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

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

    Two versions numbers are certainly confusing.

    But Isn't the "MOF" redundant too?

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

Trace Record not suitable for Incremental Execution

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

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

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

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

    This affects all of QVTc, QVTr, and QVTo.

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

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

QVTo: What are the operation overloading semantics?

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

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

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

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

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

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

QVTo: Late resolution is unuseable in multi-pass transformations

  • Key: QVT14-21
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    A late resolve() defers an assignment to such a late time that it cannot be used. Multi-pass transformations must therefore either maintain their own Dict of mappings, or use multiple transformations.

    Suggest: Allow a "late" keyword to prefix a block, so that late resolution occurs at the end of the block.

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

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

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

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

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

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

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

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

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

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

QVTo: Eliminate deprecated Typedef class


QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL

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

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

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

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

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

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

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

CLONE - current abstract syntax of ImperativeOCL introduces a couple of unclear situations

  • Key: QVT14-24
  • Legacy Issue Number: 13082
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Major Problem:
    (1) The current abstract syntax of ImperativeOCL introduces a couple of
    unclear situations. This may lead to incompatible QVT implementations.
    Further Problems:
    (2) Control flow constructs introduced by ImperativeOCL are redundant
    compared with existing conventional OCL constructs.
    (3) Several OCL equivalence rules break when ImperativeOCL is present.
    Detailed problem description:
    (1) The current abstract syntax of ImperativeOCL introduces a couple of
    unclear situations. This may lead to incompatible QVT implementations.
    In the abstract syntax, ImperativeOCL expressions / statements are
    inherited from OclExpression. Therefore, conventional OCL
    expressions may (and will) contain sub-expressions that are
    actually ImperativeOCL expressions.
    In conventional OCL, the interpretation of an expression under a
    given environment is a value. In ImperativeOCL, the interpretation
    of an expression is a value and a new environment
    (state,variables). This extended interpretation is not given for
    conventional OCL expressions, leading to undefined operational
    semantics of those expressions.
    Example: Given the following compute expression:
    compute(z:Boolean) {
    var x : Boolean := true
    var y : Boolean := true
    if ((x:=false) and (y:=false))

    { ... }

    z := y
    }
    What is the value of this expression: is it true or false (It
    depends on whether the 'and' operator is evaluated short-circuit
    or strict). The situation is similar for the evaluation of the
    other logical connectives, forAll, and exists when these
    expressions contain imperative sub-expressions.
    (2) Control flow constructs introduced by ImperativeOCL are redundant
    compared with existing conventional OCL constructs.
    Some of the new language features in ImperativeOCL such as forEach
    and the imperative conditional are not really necessary. Their
    effect can already be achieved using conventional OCL expressions:
    For example:
    company.employees->forEach(c)

    { c.salary := c.salary * 1.1}

    has the same effect as
    company.employees->iterate(c; r:OclAny=Undefined |
    c.salary := c.salary * 1.1
    )
    and
    if ( x < 0 )

    { x := 0 }

    else

    { x := 1 }

    endif is the same as
    if x < 0 then x := 0 else x := 1 endif
    (3) Several OCL equivalence rules break when ImperativeOCL is present.
    In conventional OCL, several equivalence rules well known from
    logic hold. Allowing OCL expression to contain imperative
    sub-expressions breaks these equivalence rules.
    Examples:
    let x=e1 in e2 equiv. e2

    { all occurences of x replaced by e1 }

    e1 and e2 equiv. e2 and e1
    These equivalences do not necessarily hold if e1 or e2 are allowed
    to have side-effects.
    Proposed solution:
    (A) - (The cheap solution.) State textually that conventional OCL
    expressions (as described in the OMG OCL spec.) are not
    allowed to have side effects unless used as part of a top
    level ImperativeOCL expression. Therefore, even in a system
    supporting ImperativeOCL, class invariants, and pre- and
    postconditions (e.g.) will not be allowed to contain
    ImperativeOCL sub-expressions.
    State explicitly that the redundant flow control statements
    have been introduced (solely) to write concise imperative
    programs and that the side-effect free forms of conditional
    evaluation ( 'if-then-else-endif' and 'iterate' ) shall not be
    used to program side-effects (instead, the ImperativeOCL forms
    shall be used).
    (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

  • Reported: QVT 1.0 — Mon, 5 Oct 2015 17:32 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: Missing TracePackage

  • Key: QVT14-17
  • Legacy Issue Number: 19659
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The example transformation creates numerous orphan trace classes.

    Surely these should be contained by a trace Package?

    This could be produced by a top level RelationalTransformationToTracePackage relation. RelationToTraceClass should then not be top level.

    Generation of trace is separate from core, so surely there should be a trace direction for the trace output? The core direction should use the trace direction.

  • Reported: QVT 1.2 — Fri, 21 Nov 2014 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Standard Library mode and namespace

  • Key: QVT14-13
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The QVTo Standard Library has no model and consequently no namespace.

    This encourages a major confusion:

    The QVToLib::Model and QVToLib::Transformation types used in the QVTo Standard Library are at a different meta-level to UML::Model and QVTbase::Transformation. We have the uncomfortable situation that a QVToLib::Model is an instance of a QVTbase::TypedModel and a QVToLib::Transformation is an instance of a QVTbase::Transformation.

    As a minimum the distinct namespaces should be identified and modeled.

    Possibly QVToLib::Model and QVToLib::Transformation should be renamed. Since they have no namespace they are currently unuseable in code; their sole purpose is for specification of implementation behavior.

  • Reported: QVT 1.2 — Thu, 30 Apr 2015 08:21 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTc/QVTr: Pattern.bindsTo composition

  • Key: QVT14-12
  • Legacy Issue Number: 19673
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The author of Issue 9379 misunderstood the poor description of Pattern::bindsTo and consequently removed the

    {composes} qualifier.

    Issue 10938 observed that this totally broke QVTc and introduced CorePattern::variables to compensate.

    The QVTr to QVTc transformation remains broken since it continues to assume that bindsTo {composes}

    .

    There was actually nothing wrong with bindsTo that could not have been fixed by clearer wording to the effect that bindsTo was a dustbin container for variables not contained elsewhere.

    The above kind of emphasises the benefits of an ownedPlurals naming policy. Therefore suggest that:

    a) the AST bloat from the redundant bindsTo be replaced by definition of a suitable derived property that satisfies the intent of all variables.

    b) that variables be renamed ownedVariables and used throughout the QVTr to QVTc transformation

  • Reported: QVT 1.2 — Tue, 9 Dec 2014 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

Inconsistent multiple inheritance

  • Key: QVT14-11
  • Legacy Issue Number: 18912
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance.

    For a Package: self.nestingPackage.nestedPackages->includes(self)

    For a Class:
    self.package.ownedTypes->includes(self)

    But self cannot have two containers.

    The problem is easily resolved by extending only Package and adding those Class features that are actually required.

  • Reported: QVT 1.1 — Mon, 16 Sep 2013 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: working with stereotypes:

  • Key: QVT14-10
  • Legacy Issue Number: 13158
  • Status: open  
  • Source: Siegfried Nolte ( Siegfried Nolte)
  • Summary:

    QVT Relations and working with stereotypes: Is there something like a QVT-R standard library with methods on stereotypes in it? There is none in the specification; compare QVT-R, there are some methods. Are there some else options for accessing stereotypes with QVT-R?

  • Reported: QVT 1.0 — Mon, 15 Dec 2008 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Inadequate definition of "late" semantics

  • Key: QVT14-9
  • Legacy Issue Number: 19429
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The specification of "late" semantics uses the "conceptually" word; a sure sign of missing semantics. It is followed by a magic null value that stores information for later use and with an unspecified trace interaction.

    The interaction of "late" and implicit collect is not handled so in

    generalizations := self.eSuperTypes->collect(t | t.late resolve(UML::Generalization))

    the direct association of "late" with asssignment is no longer direct; the "late"s must be aggregated. Potentuially this may occur in arbitrary complexd expressions including mapping calls!

    An alternate multi-pass interpretation of "late" is given.

    This seems like the correct approach; an MtoM transformation from a with-late to multi-pass without-late transformation.

  • Reported: QVT 1.2 — Thu, 22 May 2014 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Enhance ObjectExp to allow constructors invocation

  • Key: QVT14-8
  • Legacy Issue Number: 19023
  • Status: open  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    Problem:

    ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified.

    However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation:

    constructor Column::ColumnConstructor (n:String,t: String)

    { name:=n; type:=t; }

    object result1 : Column (“name”, “String”);
    object result2 : Column (“age”, “Integer”);

    Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint.

    context ObjectExp
    inv : argument->size() > 0 implies body.oclIsUndefined()

    Discussion:
    This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid.

    Proposed solution:

    In section 8.2.1.24 add the following subsection:

    Constraints

    If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa):

    context ObjectExp
    inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and
    not body.oclIsUndefined() implies argument->isEmpty()

    In section 8.2.1.24 add the following to the the end notation subsection:

    Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body:

    object result1 : Column (“name”, “String”);
    object result2 : Column (“age”, “Integer”);

    Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated).

    In section 8.4.7:

    Replace:

    <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
    <expression_block>

    By:

    <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
    (<expression_block> | '(' (<declarator_list>)? ')' )

  • Reported: QVT 1.1 — Wed, 23 Oct 2013 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTc/QVTr: View/Transformation discrepancy

  • Key: QVT14-5
  • Legacy Issue Number: 15411
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    "The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

  • Reported: QVT 1.1 — Tue, 10 Aug 2010 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT
  • Attachments:

QVTo: Relationship between QVTo Mapping and QVTr Relation

  • Key: QVT14-4
  • Legacy Issue Number: 15390
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.1.4 states "a mapping operation is always a refinement of an implicit relation" but 8.2.15 defines "refinedRelation: Relation [0..1] The refined relation, if any." Clearly a contradiction.

    8.1.4. provides the REL_PackageToSchema example of how an implicit relation might be defined, but no other examples or synthesis rules are supplied.

    enforce and checkonly appear in the REL_PackageToSchema example indicating that these define execution mode of a QVTo trnasformation, but there does not appear to be any description of how a transformation might be executed to for instance update an output model. Perhaps the 'output' parameter is 'inout' for create/update but 'out' for create/overwrite.

  • Reported: QVT 1.1 — Fri, 30 Jul 2010 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: syntax mapping (correction to Issue 10646 resolution)

  • Key: QVT14-3
  • Legacy Issue Number: 14640
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed. Apologies too for the long email. This is a very difficult area where precision is important. Provision of
    this resolution demonstrates the need for the resolution, but unfortunately the resolution has an
    erroneous precision that will make QVTr 1.1 unimplementable whereas QVTr 1.0 is just mildly
    ambiguous and conflicting.
    Please do not include the resolution in QVT 1.1 without significantrework.
    I found the definition of the "checkonly"/"enforce" to isCheckable/isEnforceable helpful, although
    different to three of my own intuitive guesses based on attempts to avoid errors in ModelMorf and
    Rel2Core examples.
    The problems identified below are the result of a local review of the resolution. In the absence of a
    coherent Environment semantics it has not been possible to perform a global review. In particular, I
    was unable to review the specification for the arguably redundant bindsTo.
    [Incidentally, the same resolution approach is needed for QVTc and QVTo].
    Disambiguating rules
    --------------------
    The resolution uses a similar approach to the OCL 2.0 specification, but neglects to provide any
    disambiguating rules although many are needed.
    Environments
    ------------
    OCL and the resolution employ environments to carry definitions specific to particular CS constructs,
    so that a CS reference may be resolved with the aid of an environment or the AST.
    In EssentialOCL, all definitions are resolvable with in the immutable AST with the exception of let and
    iterator expressions for which a nestedEnvironment() is used to carry the extra variable declaration
    with the aid of addElement(). The nestedEnvironment supports name occlusion from outer scopes.
    In CompleteOCL, further definitions may be introduced by a definition constraint. The OCL
    specification provides no precise insight into how an environment changes to accommodate the
    definition. Should the name be added to the AST or to the environment? Is the name available for
    forward reference?
    Environment::addElement is defined as a query operation thereby inhibiting side effects. Consequently
    usage such as
    XX.env = YY.env.addElement(Z.name, Z.ast, false)
    leaves the environment of YY unchanged and creates an extended environment for XX.
    A series of such usages creates a series of progressively elaborated environments that support
    backward but not forward referencing. This was not a clear requirement of the QVT 1.0 specification
    and it prevents any variable declarations being introduced in an object template tree being resolved
    through environments in other object template trees or predicate expressions.
    QVT 1.2 RTF Report Page 173 of 190
    Object Management Group
    RTF/FTF Report
    Imposition of no forward referencing seems very undesirable, particularly since the order of domains is
    imposed by the model parameter order. Imagine a Java program in which all methods had to be
    defined in a no-forward reference order.
    As noted above, CompleteOCL neglected to define how AST definitions were added to the AST. QVTr
    must solve this problem since QVTr defines a hierarchically scoped AST rather than an annotation of
    a pre-existing AST.
    I recommend a two stage approach. The inherited attributes section should first compute an
    environment from the pushed-down parent environment augmented by pull-ups from child constructs
    so that a complete immutable and consequently unambiguous environment is associated with each
    construct and then pushed-down to the children. During the pull-up the environment acquires a
    mapping from name to future-AST. During the push-down residual future-AST attributes are populated
    to give a valid AST.
    Reference resolution
    --------------------
    OCL uses lookup functions to resolve variable references. It is necessary either to overload the lookup
    functions so that the the distinct QVTr variable definition sites can be located in the AST, or to use
    some form of Environment::addElement where each definition is defined so that resolution in the
    environment is possible.
    Details
    =======
    Throughout, many disambiguating rules are needed to define illegal semantics. For instance "any" is
    often used to select a syntactically valid value. Corresponding usage in the OCL specification has a
    disambiguating rule to clarify what the consequence of not "one" is.
    My current best attempt at Disambiguating Rules is attached.
    Environment::addElement takes three arguments, the third being a mayBeImplicit argument. This has
    been omitted throughout without explanation.
    identifierCS
    ------------
    OCL defines SimpleNameCS. A degenerate mapping from identifierCS to SimplenameCS is required.
    topLevelCS
    ----------
    The 'imported transformation' environment element is later referenced as 'imported transformations'.
    Typo: TransformationListCS for transformationListCS in Synthesized attributes.
    importListCS
    ------------
    Semantics of import conflicts must be defined.
    unitCS
    ------
    Typo: ast is not a Set.
    Surely the import is of packages (enumerations or operations)or at least transformations (QVTo
    implementations) rather than necessarily relational-transformations?
    transformationCS
    ----------------
    QVT 1.2 RTF Report Page 174 of 190
    Object Management Group
    RTF/FTF Report
    ownedTag is not synthesized.
    keyDeclListCS
    -------------
    Typo: wrong font in synthesized attributes
    modelDeclCS
    -----------
    The [B] grammar:
    modelDeclCS ::= modelIdCS ':' '

    {' metaModelIdListCS '}

    '
    is missing.
    keyDeclCS
    ---------
    Synthesized attributes appear to have experienced a copy and paste error while providing distinct part
    and oppositePart left hand sides.
    keyPropertyCS
    -------------
    The synthesized attributes poke the parent.
    Suggest: it would be clearer for the parent to gather and distribute children similar to the relation/query
    allocation by transformationCS.
    relationCS
    ----------
    Transformation.extends does not appear to be transitive.
    topQualifierCS
    --------------
    Suggest: a boolean or enumerated value rather than a string.
    domainListCS
    ------------
    Typo: missing indentation.
    primitiveTypeDomainCS
    ---------------------
    isCheckable, isEnforceable not synthesized.
    objectTemplateCS
    ----------------
    Variable needs to be added to relation to provide a container.
    Variable needs to be added to relation environment to provide visibility.
    collectionTemplateCS
    --------------------
    Variable needs to be added to relation to provide a container.
    Variable needs to be added to relation environment to provide visibility.
    Suggest: last two if guards are redundant.
    QVT 1.2 RTF Report Page 175 of 190
    Object Management Group
    RTF/FTF Report
    restCS
    ------
    Variable needs to be added to relation to provide a container.
    Non-_ named variable needs to be added to relation environment to provide visibility.
    memberCS
    --------
    Variable needs to be added to relation to provide a container.
    Non-_ named variable needs to be added to relation environment to provide visibility.
    whenCS
    ------
    predicateListCS should be optional.
    whereCS
    -------
    predicateListCS should be optional.
    ExtOclExpressionCS
    ------------------
    This is not present in the QVTr or OCL grammar.
    Presumably it represents the QVTr extension to OCL's OclExpressionCS.
    However it is an extension, since at least RelationCallExpCS can be used in an ordinary
    OclExpressionCS using "not" or "and".
    [A], [B], [C] should therefore follow on from OCL's
    [A], [B], [C]..., [I].
    RelationCallExpressionCS
    ------------------------
    How is a RelationCallExpressionCS distinguished from an OperationCallExpCS?

  • Reported: QVT 1.1 — Mon, 16 Nov 2009 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: BlackBox operation signature difficulties

  • Key: QVT14-2
  • Legacy Issue Number: 13054
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so:

    package QVTBase

    context TypedModel
    def: allUsedPackage() : Set(EMOF::Package)
    = self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage)

    endpackage

    package QVTRelation

    context RelationImplementation
    inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package)

    endpackage

    This is not satisfied by almost the last line of RelToCore in 10.3:

    enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me);

    which seems to have output second.

    -----------------------------------------------------

    More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation.

    This semantic clumsiness could be resolved, if, within a transformation,
    relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output.

    The RelToCore example can then be mended by declaring that:

    RelToCore(...) extends utils::CopyUtilities

    and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.

  • Reported: QVT 1.0 — Fri, 31 Oct 2008 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: Deletion semantics

  • Key: QVT14-7
  • Legacy Issue Number: 15886
  • Status: open  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    I’m having trouble with the semantics of DELETE on p. 189 of the QVT Specification (v1.1). It reads in part:

    FORALL OBJVAR IN MAKESET(<DOMAIN_K_VARIABLE_SET>) (
    …
    AND BELONGSTO(OBJVAR, MAKESET(<DOMAIN_K_VARIABLE_SET>))

    I guess I don’t understand MAKESET and BELONGSTO. First of all, <DOMAIN_K_VARIABLE_SET> is already a set, so what’s the MAKESET function do? Second, the FORALL iterates OBJVAR over the results of the same MAKESET that BELONGSTO tests. So how can BELONGSTO be false? That is, I would assume BELONGSTO is defined as follows:

    BELONGSTO(e, S) º e ÎS

    except that under this definition the expression above is always satisfied.

    Any and all help appreciated. Thank you very much.

  • Reported: QVT 1.1 — Tue, 12 Oct 2010 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: Undefined semantics

  • Key: QVT14-1
  • Legacy Issue Number: 10936
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The whole Concrete Syntax section deserves a much more substantial description.

    In particular...

    The mechanism by which a package name is located is unresolved, perhaps deliberately,
    but the omission should be explicit.

    What constraints exist on forward referencing of names?

    Transformations and mappings could be ordered so that forward references are avoided,
    but large modules benefit from an alphabetical ordering of elements, so requiring
    a parser friendly order is not user friendly.

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT