8.1.8 has
column := self.attribute->new(a) Column(a.name,getSqlType(a.type));
Surely the (a) is a typo?
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?
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.
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.
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 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:
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.
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).
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.
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".
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.
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.
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.
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.
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 }}
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,
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?
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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}}
; // 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}};
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.
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.
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'.
8.4.4. bullet 6 says both available.
Following bullet 8 it says only one or the other available.
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.
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.
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.
8.4.4 at the end has
use-traditional-comparison-sysntax
where surely
use-traditional-comparison-syntax
was intended.
8.4.7 defines a "!->" access_op but there is no accompanying specifucation.
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.
The following shorthands are missing from 8.4.5
anExpression[aTypeExp]
anExpression[anotherExpression]
!
!->
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?
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.
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.
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.