MOF Query/View/Transformation Avatar
  1. OMG Specification

MOF Query/View/Transformation — Open Issues

  • Acronym: QVT
  • Issues Count: 38
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
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-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-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

Issues Descriptions

QVTr: Single argument RelationCallExp is not crazy

  • Key: QVT14-65
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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

QVTc - overrides/overidden are confusing

  • Key: QVT14-52
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 ( Ed 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 : 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 ( Ed 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 ( Ed 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 ( Ed 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