Issue 19162: Section 9.2 - 9.3: (ifml-ftf) Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com) Nature: Uncategorized Issue Severity: Summary: Issue: Simplify description of history management. Remove references to context and contextual flows Resolution: Rephrasing has been applied throughout Clause 9 for removing the concept of context and contextual flows. Final text reported below. Revised Text: 9.1Introduction This clause specifies the execution semantics of IFML. The purpose is to define when and how to compute the values to be shown to the user, based on an IFML Model. A few aspects affect the execution semantics: 1. Triggering events 2. Parameter propagation 3. Navigation history preservation 9.2Relevant Aspects for IFML Execution Semantics 9.2.1Triggering Events The content of a ViewContainer must be (partially or completely) computed when the following events arise: 1. Inter-container navigation flow traversal: The container is entered through a NavigationFlow originated by an Event in another container. 2. Intra-container navigation flow traversal: The user produces an Event inside a container that triggers the navigation of a flow targeting an Element in the same ViewContainer (e.g., Window). Firing the navigation may have side effects on the content of the currently visualized Elements (e.g., it may modify content currently shown to the user) and may invalidate (partially or totally) the information used to compute the container. 9.2.2Parameter Propagation A ViewContainer typically contains several pieces of related information. This corresponds to having several ViewComponents linked in a network topology through NavigationFlows and DataFlows. Information may be propagated from one ViewComponents to other ViewComponents through ParameterBindings. Actual propagation depends on the Events that trigger the flows. The general behavior is as follows: 1. NavigationFlows are triggered only when the triggering Event happens. Only one event at a time can happen. Parameters on NavigationFlows are transferred only when the NavigationFlow is triggered. 2. DataFlows toward ViewElements contained in the same ViewContainer are triggered any time some output parameter is available in the source ViewElement. Parameters on DataFlows are transferred when the DataFlow is triggered. 3. DataFlows toward Actions or toward ViewElements contained in another ViewContainer are triggered only when a corresponding NavigationFlow toward that Action or toward that ViewContainer is triggered. Parameters on DataFlows are transferred when the DataFlow is triggered. Conflicts may arise in the propagation of Parameters. A conflict arises when a ViewElement or Action receives more than one input value for the same Parameter. This could happen due to multiple incoming flows. A conflict resolution strategy (CRS) specifies which Parameter value is selected to compute the data content of the ViewComponent. A conforming tool shall use one of the following possible strategies: 1. Non-deterministic choice: One input parameter is chosen non-deterministically at run-time among the set of available inputs. 2. With priorities: Priorities are assigned at design-time to the incoming flows (for the ViewComponent or ViewContainer), and, in case of run-time conflict, the Parameter value transported by the flow with highest priority is chosen. Priorities define a total ordering on the incoming flows for the ViewComponent or ViewContainer. 3. Mixed: A partial order of prioritization is defined at design-time over the input flows, and, in case of run-time conflict, the Parameter values transported by the flow with highest priority is chosen. If the ViewContainer is accessed at run-time in such a way that multiple flows with highest priority are in conflict, a non-deterministic choice is taken. 9.2.3Navigation History Preservation When the user triggers an Event, the content of the destination ViewContainer is refreshed, in a way that may depend on the past history of the user interaction. The alternatives for re-computing a ViewContainer (or a part thereof) depends on the “degree of memory” used for computation. A conforming tool may use one of the following possible interaction history policies: 1. Without history: The contents of the ViewComponents in a ViewContainer are always computed as if the ViewContainer was accessed for the first time. The computation without history policy may be used to “reset” and forget the choices done by the user in the past. Only the current Parameter values are used for computation. 2. With history: The contents of the ViewComponents are computed based on the input history of the ViewComponents existing prior to the last navigation event. This means that the past parameter values are preserved and reused for computation, except if newer values become available. 9.3ViewComponent Computation Process The following algorithm is used for computing the content of a generic ViewContainer, with particular attention to containers of type Window. The computation process is performed every time an Event arises. The process tries to determine the data content of all the ViewComponents of the ViewContainer, taking into account the semantic aspects discussed in Clause 9.2. Intuitively, the process determines at each step the set of computable ViewComponents, i.e., the subset of ViewComponents that receive their input Parameters and therefore can be calculated. A ViewComponent is computable if it has no incoming InteractionFlows or if it has incoming InteractionFlows and the following conditions are satisfied: 1. The ViewComponent has not been already computed (a ViewComponent cannot be computed more than once upon the same Event, and the first computation holds). 2. All the ViewComponents from which the ViewComponent may receive Parameters have been computed already. 3. All the input Parameters needed to compute the ViewComponent have a value. If the computation semantics of the ViewContainer is without history, only current input parameters are considered in point 3. If the computation semantics is with history, components may draw their input values either from current Parameter values (if available) or from the past Parameter values, existing prior to the last flow navigation. For computing the contents of the ViewComponents within a ViewContainer, the algorithm must receive in input: • the ViewContainer to compute, • the set of ViewComponents to be considered in the computation (initially all the ViewComponents of the ViewContainer), • the conflict resolution strategy, • the interaction history policy, • the past Parameter values of all the ViewComponents prior to the last flow navigation, • the destination ViewComponent of the fInteractionFlow whose navigation has produced the computation event together with the past Parameters transported by the flow. The following steps of the algorithm are then carried out: 1. Component invalidation: If the destination of the navigated flow is a ViewComponent, all its dependent ViewComponents are invalidated, i.e., their input parameters are set to null and therefore the ViewComponents need to be recomputed. (We say that ViewComponent c1 depends onViewComponent c2 if c1 can be reached through NavigatioFlows from c2.) 2. Non-invalidated component computation: One ViewComponent at a time is computed, until all possible components are considered. At each step, if there is at least one computable ViewComponent, one of them is selected and its content is computed, based on the conflict resolution strategy, the interaction history policy, and the past Parameter values. In particular: 1. If a ViewComponent does not depend on any other ViewComponent, i.e. it does not expect any input Parameter, it can always be computed. 2. If a ViewComponent is the destination ViewComponent of the InteractionFlow whose navigation has produced the computation event, then the past and new values of the flow Parameters are used for computing the component. 3. In all the other cases, the interaction history policy determines which input Parameters must be used. If the interaction history policy is “without history”, one of the possible current input Parameters is chosen, according to the conflict resolution strategy. If the interaction history policy is “with history” the past values of the input Parameters are considered. If the past values are available and no newer value is available for that Parameter, the old value is used to instantiate the ViewComponent; if no past values of input Parameter for the component is available, one of the possible input Parameter values is chosen according to the conflict resolution strategy. Actions taken: December 9, 2013: received issue July 15, 2014: closed issue Discussion: End of Annotations:===== s is issue # 19162 From: Marco Brambilla Issue 13: Section 9.2 - 9.3: Issue: Simplify description of history management. Remove references to context and contextual flows