Re: [qvto-dev] Fwd: [omg] [QVT13] Ballot #5 is ready for review until We

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

I interpreted the trace of an 'accessed' transformation as the trace of mapping in Tx1 that is accessed during the execution of Tx2 as a consequence of Tx2 inheriting/extending Tx1 with access semantics; not as a consequence of Tx2 nesting/executing e.g. Tx1.transform(). The proposed QVT 1.3 resolution clearly includes all trace from 'inherited' mappings and excludes all 'nested' mappings.

I raised http://solitaire.omg.org/browse/QVT13-124 suggesting that the solution to 'nested' traces may be for the trace-data to form part of the Status which could be an optional additional first resolveXXX argument.

...resolveIn(tx1Status, Tx1:::A::m);

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.

If you care to prototype this suggestion, it can guide a resolution for QVT 1.4. The hidden cloning issue to support distributed parrallelTransform() needs careful attention.

Tracing only Mapping invocation/execution is indeed limiting. Adding a Transformation Invocation trace-record could be useful. Adding an Object construction trace record could also be useful. Perhaps even an Object mutation trace record to make sure your disk fills up. Once again prototype something better and raise an issue.

    Regards

        Ed Willink

On 22/10/2015 09:26, Christopher Gerking wrote:

Hi

 

To be honest, I’m unhappy with the resolution of QVT13-22.

 

The QVT13-23 resolution implies that there is a trace record for every mapping execution, “but not those by transformation invocations”. That’s exactly what this issue is about. If there are no trace records for mappings executed inside an accessed transformation, the entire trace of the accessed transformation gets lost after its termination. This reduces the possibilities for transformation composition: if I need full traceability, I can’t decompose my transformation into subparts, and vice versa. However if I have a stepwise transformation with intermediate models, I’m actually dependent on “accessing” sub-transformations (intermediate models won’t work otherwise). I’m actually suffering from exactly this dilemma with one of my transformations where I need full traceability.

 

I agree that, due to parallelTransform(), an accessed transformation shouldn’t reuse the trace data of the accessing transformation. But why is there no write-back after the termination of transform() or parallelTransform() ? Exposing a trace is often useful and never hurts.

 

In any case, the resolution text is somewhat contradictive: there are trace records for accessed transformations, but not for transformation invocations. That’s a contradiction, because an accessed transformation must always be invoked explicitly.

 

 

Kind regards

Christopher