In re: #102. The problem with an invocations array is that it basically creates a nested set of runs within a run object. This has become a clear problem now that we have tool.extensions. How does an invocation associate its results with one of these extensions? We have lost the coherent definition of a tool run if we permit this. Elsewhere in the design, we allow invocationIndex to associate a result with an invocation.
We got this wrong. Instead of an array of invocations, a run should be strongly associated with a single conceptual process/execution/analysis, with a single tool object (with all extensions described) and a single invocation object.
If a system has some sort of notion of chaining invocations in order to create an end-to-end analysis session, the constituent elements should be persisted as discrete run objects that describe all phases. The run id's logical/instance identifier can be used to associate all these elements into a single set. This id can even be used to order them if necessary (by incrementing a counter in the hierarchical id).
Specific proposal: make invocation a single instance of the invocation object and drop invocationIndex. Note that this change also helps alleviate the look-up pain we've introduced by adding extensions and other array items.
@lgolding , FYI.
In re: #102. The problem with an invocations array is that it basically creates a nested set of runs within a run object. This has become a clear problem now that we have tool.extensions. How does an invocation associate its results with one of these extensions? We have lost the coherent definition of a tool run if we permit this. Elsewhere in the design, we allow invocationIndex to associate a result with an invocation.
We got this wrong. Instead of an array of invocations, a run should be strongly associated with a single conceptual process/execution/analysis, with a single tool object (with all extensions described) and a single invocation object.
If a system has some sort of notion of chaining invocations in order to create an end-to-end analysis session, the constituent elements should be persisted as discrete run objects that describe all phases. The run id's logical/instance identifier can be used to associate all these elements into a single set. This id can even be used to order them if necessary (by incrementing a counter in the hierarchical id).
Specific proposal: make invocation a single instance of the invocation object and drop invocationIndex. Note that this change also helps alleviate the look-up pain we've introduced by adding extensions and other array items.
@lgolding , FYI.