Re: [qvto-dev] QVT 1.3 Traceability proposal

[Christopher Gerking <christopher.gerking@xxxxxxxxxxxxxxxx>]

Hi

 

Well done. Some comments below.

 

 

“This relationship can be queried by the execution of another mapping”.

 

I disagree. Resolving has no side-effects, so it should be possible to access trace data also from other types of operations like queries or helpers.

 

 

“This including any mappings executed by accessed or extended transformations or libraries”.

 

I basically agree. But what does this mean for resolving from within an accessed transformation? Is the trace data from the accessing transformation available? So is there an immediate write-through? That’s dangerous, because if one transformation accesses two other transformations (which share some mapping operations), the second transformation might fall over trace records created by the first one.

 

Alternatively, an accessed transformation could start with an empty trace data. At the end of the nested execution, there would be a write-back to the trace of the accessing transformation. I consider this as the most generally compatible solution.

 

Overall, the initial trace data should depend on whether the accessed transformation reuses the model extents from the accessing transformation. But I think this would imply too many hybrid forms and twilight areas for a clean specification.

 

 

“The trace record is created […] at the start of the initialization section of the selected candidate mapping.”

 

That’s earlier than before. I see the advantage that some unnecessary re-executions can be prohibited, but only if one and the same mapping is re-executed (directly or indirectly) from within in its own init section. Are there other advantages in creating the trace record earlier?

 

 

“The initially null value of the out-parameters and result-parameters fields is updated at the end of the candidate mapping execution.”

 

Does “at the end” mean after the end section? That’s later than it was before. The problem is that the change excludes the possibility of calling resolveIn(M) from within the body of M. That’s a pity because the results do already exist. So why not resolving them, even if uninitialized?

 

 

“These queries return the sequence of target objects.”

 

Should the order of that sequence be specified?

 

 

“However if multiple resolutions are available, the assertion is that there is at most one resolution is not satisfied and execution fails”.

 

That’s quite an influential change. I see the advantages. However I wonder if there are too many situations where resolveone(…) is used as a plain shortcut for resolve(…)->first() or resolve(…)->any(…). Especially when using resolveone(OCL-condition), the expected result could often be any random object that satisfies the condition, even if there are more than one candidates. Also expressions like resolveone(EClass) are quite silly, because there will be more than one EClass in almost any case.

 

 

“The ordering in which late resolutions occur does not matter, since each late resolution can influence only its own deferred assignment.”

 

But the execution order of the assignments does matter. Especially in case of opposite references. Can local variables be used to “buffer” lateresolve results for re-access in a subsequent lateesolve? Don’t underestimate the assignment order.

 

 

“The body of the disjuncting mapping is not executed.”

 

There shouldn’t be a body, as you described right below.

 

 

Kind regards

Christopher

 

Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Montag, 12. Oktober 2015 12:57
An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
Betreff: [qvto-dev] QVT 1.3 Traceability proposal

 

Hi

My proposed resolution to clarify tracing and resolution is below.

Please read carefully. The clarifications impose some subtly stronger requirements. The tracing of DataType values implies deep cloning in ways that I thought would be correct but unacceptable. But looking at the QVTo implementation it appears that EValue clones.

    Regards

        Ed Willink

In 8.1 before 8.1.10 Add a new section

8.1.x Tracing and Resolving

Execution of a mapping establishes a trace record to maintain the relationship between its context object and the result object or objects. This relationship can be queried by the execution of another mapping using one of the eight resolve operations.

8.1.x.1 Trace Records

Execution of a transformation builds the overall trace data which comprises a sequence of trace record; one for each mapping execution. This including any mappings executed by accessed or extended transformations or libraries. Each trace record comprises:

• context-parameter - the context (or source) parameter object
• in-parameters - the in (and inout) parameter objects or values
• invoked-mapping - the invoked mapping operation
• executed-mapping - the executed mapping operation
• out-parameters - the out (and inout) parameter objects or values
• result-parameters - the result (or target) parameter object or objects

The invoked-mapping and executed-mapping operations may differ when a disjuncting mapping is invoked. The invoked-mapping is the disjuncting mapping. The executed-mapping is the successfully selected candidate mapping or null.

inout parameters are traced twice, once as in-parameters and again as out-parameters.

The trace record is created with context-parameter, in-parameters, invoked-mapping and executed-mapping fields at the start of the initialization section of the selected candidate mapping. This is after predicates have been executed as guards or pre-conditions. The initially null value of the out-parameters and result-parameters fields is updated at the end of the candidate mapping execution. In the case of a standard mode execution for which no candidate mapping is selected, the trace record contains null entries for executed-mapping, out-parameters and result-parameters fields.

The trace record traces the source/target relationship; it does not trace object construction or helpers. If a trace is needed, these untraced facilities must be wrapped up inside a mapping.

8.1.x.2 resolve() - Resolution of target objects by Type

The trace data may be queried to identify all target objects using the resolve operation without a context object or argument.

    resolve();

The query may be restricted to identifying all target objects conforming to a given type by adding a type argument.

    resolve(Table);

The returned target objects may be further restricted to those mapped from a particular source object by supplying the source object as the context object.

    source.resolve(Table);

Additionally, or alternatively, the returned target objects may be restricted by an OCL condition.

    source.resolve(t : Table | t.name.startsWith('_'));

These queries return a sequence of target objects.

An equivalent OCL-like query for SOURCE.resolve(T : TYPE | CONDITION) is

let selectedRecords = trace-data->select(in-parameters->including(context-parameter)->includes(SOURCE)) in

let selectedTargets = selectedRecords->collect(out-parameters->union(result-parameters))->flatten() in

selectedTargets->selectByKind(TYPE)->select(T | CONDITION)

8.1.x.3 resolveIn() - Resolution of target objects by Mapping

The trace data may be queried to identify all target objects produced by a given invoked disjuncting mapping or executed candidate mapping using the resolveIn operation.

    resolveIn(Class2Table);

The returned target objects may be restricted to those mapped from a particular source object by supplying the source object as the context object.

    source.resolveIn(Class2Table);

Additionally, or alternatively, the returned target objects may be restricted by an OCL condition.

    source.resolveIn(Class2Table, t : Table | t.name.startsWith('_'));

These queries return a sequence of target objects.

An equivalent OCL-like query for SOURCE.resolveIn(MAPPING, T : TYPE | CONDITION) is

let selectedRecords1 = trace-data->select(in-parameters->including(context-parameter)->includes(SOURCE)) in

let selectedRecords2 = selectedRecords1->select((invoked-mapping = MAPPING) or (executed-mapping = MAPPING)) in

let selectedTargets = selectedRecords2->collect(out-parameters->union(result-parameters))->flatten() in

selectedTargets->selectByKind(TYPE)->select(T | CONDITION)

8.1.x.4 invresolve() - Resolution of source objects by Type or Mapping

The corresponding inverse queries identifying source objects conforming to a given type or mapping is available using the invresolve or invresolveIn operations.

    target.invresolve(t : Table | t.name.startsWith('_'));

    target.invresolveIn(Class2Table, t : Table | t.name.startsWith('_'));

8.1.x.5 resolveone() - Resolution of a single source or target object by Type or Mapping

The four resolveone variants of the four resolve operations modify the return to suit the common case where only a single object is expected. The normal return is therefore the resolved object or null. However if multiple resolutions are available, the assertion that there is at most one resolution is not satisfied and execution fails,.

    source.resolveone(t : Table | t.name.startsWith('_'));

    source.resolveoneIn(Class2Table, t : Table | t.name.startsWith('_'));

    target.invresolveone(t : Table | t.name.startsWith('_'));

    target.invresolveoneIn(Class2Table, t : Table | t.name.startsWith('_'));

8.1.x.6 Late resolution

The resolve operations query the prevailing state of the trace data. resolve cannot therefore return results from mappings that have yet to execute. This may require careful sequencing of mapping execution. Alternatively a late keyword may prefix the resolve when the resolve occurs within an assignment. This defers the execution of the assignment and the partial computation involving late resolve's until all mapping executions have completed. More precisely, mappings execute, assignment right hand sides involving late resolutions are computed, then finally deferred assignments are made. The ordering in which late resolutions occur does not matter, since each late resolution can influence only its own deferred assignment.

myprop := mylist->late resolve(Table);

      // shorthand for mylist->xcollect(late resolve(Table))

This last example also demonstrates that an implicit imperative xcollect of resolutions may be performed, in this case requiring the collection to be performed after all mappings have executed.

8.1.x.7 Redundant execution

The trace data is used to suppress re-execution of any previously executed mapping in favor of the previous execution.

A candidate mapping execution is suppressed to avoid creating a trace record whose context-parameter, in-parameters, invoked-mapping and executed-mapping fields duplicate another trace record is already in the trace data. When comparing trace record fields, Class instances are compared as objects without regard for their content, and DataType values are compared by deep value equality. Traced object instances may therefore be modified between mapping executions without inhibiting detection of re-execution since only the object references are traced. However any modification of a traced DataType value such as a List inhibits detection of a re-execution since the entire value is traced.

When a re-execution attempt is detected, the re-execution is suppressed without any additional trace record being created. The out-parameters and result-parameters fields of the previous execution are re-used as the corresponding returns of the re-execution attempt.

8.1.x.8 Persisted Trace Data

The trace data may be persisted and reloaded to support a re-execution. However since the trace record does not trace multiple object states, configuration data, transformation context or intermediate data, it is not possible to use a persisted form of the trace data to support incremental re-execution of an arbitrary QVTo transformation. A well-behaved transformation that avoids mutating objects or other untraced facilities may be re-executable.

In 8.2.1.15 Correct

A mapping operation is an operation implementing a mapping between one or more source model elements- intoand one or
more target model elements.

In 8.2.1.15 Replace

The when clause acts either as a pre-condition or as a guard, depending on the invocation mode of the mapping
operation.

by

The when clause acts either as a pre-condition when invoked with strict semantics, or as a guard, when invoked using standard semantics.

In 8.2.1.15 Replace

The initialization section is used for computation prior to the effective instantiation of the outputs. The population section is used to populate the outputs and the finalization section is used to define termination computations that take place before exiting the body.

by

The init (initialization) section is used for computation prior to the effective instantiation of the outputs. The population section is used to populate the outputs and the end (finalization) section is used to define termination computations that take place before exiting the body.

In 8.2.1.15 Correct

There are threetwo reuse and composition facilities associated to mapping operations:

In 8.2.1.15 Replace

3. A mapping operation may be defined as a disjunction of other mapping operations. This means selecting, among the
set of disjuncted mappings, the first that satisfies the when clause and then invoking it. The execution semantics subsection
below provides the details of these reuse facilities.

by

A disjuncting mapping operation may be defined as an explicit disjunction of candidate mapping operations. This means selecting and executing the first candidate mapping whose when clause and other predicates are satisfied. The body of the disjuncting mapping is not executed. An implicit disjunction of candidate mappings is formed by overloaded mappings with matching name and argument count.

The execution semantics subsection below provides the details of these reuse facilities.

In 8.2.1.15 Constraints add

The body of a disjuncting mapping must be empty.

disjunct->notEmpty() implies body = null

In 8.2.1.15 Replace

We first define the semantic of the execution of a mapping operation in absence of any reuse facility (inheritance, merge, and disjunction), then we describe the effect of using these facilities.

by

We first define the semantic of the execution of a mapping operation in absence of any inheritance or merge reuse facility, then we describe the effect of using these facilities.

n 8.2.1.21 Replace

Indicates the mode of the mapping invocation.

by

Indicates the mapping invocation mode is strict or standard.

In 8.2.1.21 Replace

In strict mode the when clause is evaluated as a pre-condition. In contrast, when the mapping is invoked in standard mode, the execution of the mapping body is skipped and the null value is returned to the caller.

by

In strict mode failure to evaluate the when clause as a pre-condition causes the mapping execution to fail. In contrast in standard mode, failure to evaluate the when clause as a guard causes execution of the mapping body to be skipped and null to be returned to the caller.

In 8.2.1.21 Correct

The map and xmap keywords may be called on a listcollection as source

In 8.2.1.22 Correct

where the <resolve_op> is one of the following: resolve, resolveone, invresolve, and invresolveone.

In 8.2.1.22 Correct

When isDeferred is true the latelate keyword is used before the operation name<resolve_op>.

In 8.2.1.22 Correct

The resolution operator may be called on a listcollection. This is a shorthand for invoking it in the body of a ForExp _expression_.

In 8.2.1.22 Replace

// shorthand for mylist->forEach(i) { i.late resolve(Table); }

by

// shorthand for mylist->xcollect(late resolve(Table))