Hi
Misunderstanding,
I see.
IMHO
composition should not affect a transformation’s visible
behavior. From the viewpoint of resolve() it shouldn’t make
a difference whether a trace link was recorded at the very
same level or on a sublevel. Consequently I also consider
transformation composition as some kind of a refactoring
capability. I might have a huge transformation which uses
resolve/invresolve in certain places. A refactoring could
introduce a nested sub-transformation, but then there must
be a way to make the resolve/invresolve still work.
I
prototyped something “better” (?) years ago for Eclipse
QVTo, which does currently expose the nested trace:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=392153
My
approach might be problematic, because it involves passing
the trace data of the accessing transformation into the
accessed transformation. Thus in fact there is only one
trace. But at least there are large-scale transformations
relying on this practice very successfully.
Binding
the trace to the transformation status is not really
helpful, because in case of 100 chained sub-transformations
I don’t want to invoke resolve(…) a hundred times. Anyway,
how to propagate the Status across multiple levels? If A
accesses B and B accesses C, is there any possibility for A
to resolve what has happened during C?
What’s
the real reason against a default back-propagation of the
trace data? Confidentiality? That’s usually not an issue
when it comes to model transformation. As long as the
interplay between composition and traceability is unclear,
any unfounded restrictions are inappropriate. As a QVTo
user, I don’t want to decide between composition and
traceability.
Regards
Christopher
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
