Issues for IFML 1.0 Finalization task Force
To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 18574: Two of the XMI files use the XMI 2.1 namespace instead of XMI 2.4 Jira Issue IFML-2
Issue 18915: Content of Field Class Jira Issue IFML-20
Issue 18916: Fix Figure 50 Jira Issue IFML-21
Issue 18917: Parameter scope Jira Issue IFML-22
Issue 18918: actions in containers Jira Issue IFML-23
Issue 18919: module defs Jira Issue IFML-24
Issue 18920: Default container Jira Issue IFML-25
Issue 18921: Add Window in table 1 Jira Issue IFML-26
Issue 18922: Modality in Table 1 Jira Issue IFML-27
Issue 18923: add event type onLoad Jira Issue IFML-28
Issue 18924: Fix Figure 64 Jira Issue IFML-29
Issue 18925: An List - fix typo Jira Issue IFML-30
Issue 18926: Action description Jira Issue IFML-31
Issue 18927: Menu ViewContainer Jira Issue IFML-32
Issue 18928: wrong component in figure 54 Jira Issue IFML-33
Issue 18929: throwing events in examples Jira Issue IFML-34
Issue 18930: MessageWritter typo Jira Issue IFML-35
Issue 18931: MessageReader in example Jira Issue IFML-36
Issue 18932: misplaced img Jira Issue IFML-37
Issue 18933: parameter direction Jira Issue IFML-38
Issue 18934: parameters of field Jira Issue IFML-39
Issue 18935: Form class description Jira Issue IFML-40
Issue 18936: data access typo Jira Issue IFML-41
Issue 18937: ports in modules Jira Issue IFML-42
Issue 18938: symbol of submit event Jira Issue IFML-43
Issue 18939: throwing and catching events Jira Issue IFML-44
Issue 18940: JUMP event type Jira Issue IFML-1
Issue 18941: view components in examples Jira Issue IFML-45
Issue 18942: connection to BPMN Jira Issue IFML-46
Issue 18943: actions Jira Issue IFML-47
Issue 18944: modules in UML profile Jira Issue IFML-48
Issue 18945: extensibility Jira Issue IFML-49
Issue 18946: content model Jira Issue IFML-50
Issue 19040: Rename submit and select events Jira Issue IFML-51
Issue 19041: Add Default value to parameters Jira Issue IFML-52
Issue 19042: An event can have at most one incoming and one outgoing flow Jira Issue IFML-53
Issue 19043: Add SetContext event Jira Issue IFML-54
Issue 19044: context variables Jira Issue IFML-55
Issue 19045: Outgoing flows from actionevents Jira Issue IFML-56
Issue 19046: Dangling actions Jira Issue IFML-57
Issue 19047: Fig. 53 and all others that include a XOR Jira Issue IFML-58
Issue 19048: History and default context are not defined Jira Issue IFML-59
Issue 19049: parameterBinding [0..*] Jira Issue IFML-60
Issue 19050: triggeringExpression [1..*] Jira Issue IFML-61
Issue 19051: system event Jira Issue IFML-62
Issue 19052: Description of some association ends Jira Issue IFML-63
Issue 19053: isLandmark Jira Issue IFML-64
Issue 19054: viewelementevent cannot be associated with viewcomponentpart Jira Issue IFML-65
Issue 19055: ViewComponentPart: association with interactionflow is missing Jira Issue IFML-66
Issue 19056: Conditional expression can have outgoing flow Jira Issue IFML-67
Issue 19057: viewelementevent can be associated with 0..1 viewelements Jira Issue IFML-68
Issue 19058: rewrite In ConditionalExpression (8.3.6) Jira Issue IFML-69
Issue 19059: Replace ContentAccess with DataBinding Jira Issue IFML-70
Issue 19064: Change content-model in domain-model Jira Issue IFML-71
Issue 19065: Class Form - wrong description text Jira Issue IFML-72
Issue 19066: Wrong associations in Class Form Jira Issue IFML-73
Issue 19150: Section 1: scope Jira Issue IFML-3
Issue 19151: Section 6.4: acknowledgements Jira Issue IFML-4
Issue 19152: Section 8.1.4: Jira Issue IFML-5
Issue 19153: Section 8.1.7 Jira Issue IFML-6
Issue 19154: Section 8.1.6 Jira Issue IFML-7
Issue 19155: Section 8.3.24: Jira Issue IFML-8
Issue 19156: Section 8.3.27: Jira Issue IFML-9
Issue 19157: Section 8.3.28 Jira Issue IFML-10
Issue 19158: Section 8.4.4: Jira Issue IFML-11
Issue 19159: Section 8.3.32 - 8.3.33: Jira Issue IFML-12
Issue 19160: Section 8.4.4: SubmitEvent property must be removed in text (not there in metamodel) Jira Issue IFML-13
Issue 19161: Section 8.4.9: Jira Issue IFML-14
Issue 19162: Section 9.2 - 9.3: Jira Issue IFML-15
Issue 19163: Section 11.3 Jira Issue IFML-16
Issue 19164: Chapter 11: Jira Issue IFML-17
Issue 19165: Section 6.3: Jira Issue IFML-18
Issue 19180: Low resolution images in specification Jira Issue IFML-19
Issue 19195: Figure 3 - wrong diagram Jira Issue IFML-74
Issue 19200: Class Expression description to be fixed Jira Issue IFML-75
Issue 19203: DI and DD specifications need to be fixed based on the changes to the MM Jira Issue IFML-76
Issue 19206: Fig. 5 - ContentModel references UML Element Jira Issue IFML-77
Issue 18574: Two of the XMI files use the XMI 2.1 namespace instead of XMI 2.4 (ifml-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Revision
Severity:
Summary:
Two of the XMI files use the XMI 2.1 namespace instead of XMI 2.4
Resolution: XMI namespace version has been fixed to 2.4
Revised Text:
Actions taken:
March 21, 2013: received issue
July 15, 2014: closed issue
Issue 18915: Content of Field Class (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Field can contain any sub-viewcomponentpart, not only slot. remove rule from Field Class: Constraints � viewComponentPartsAreSlots self.subViewComponentPart -> forAll(v | v.oclIsTypeOf(Slot))
Resolution: Constraint Removed
Revised Text: Constraint Removed in clause 8.4.3 - �Field�: viewComponentPartsAreSlots self.subViewComponentPart -> forAll (v | v.oclIsTypeOf(Slot))
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18916: Fix Figure 50 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: In figure 50: The model of the interaction flow for moving a message to an existing or newly created tag: - the XOR container is not needed - add the needed dataflow to the second action CreateTag - the missing parent Folder must be added - fix the newPage event
Resolution: Figure 50 fixed by: removing the XOR container and adding the missing DataFlow.
Revised Text:
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18917: Parameter scope (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Define the scope of parameters. It's not clear where parameters can be referenced. A sensible rule can be: Scope of the parameter is the component or container where defined, plus everything contained in it.
Resolution: Scope and type of parameters are clarified in Clause 8.3.27 in a new piece of text.
Revised Text: New text added at the end of Clause 8.3.27 - Parameter: The scope of a Parameter (i.e., the model space where it can be used or referenced) is the InteractionFlowElement that holds the Parameter, plus the incoming and outgoing InteractionFlows. This means that: if the parameter is held by a ViewComponent, it can be referenced only within the ViewComponent itself and the contained ViewComponentParts (plus the incoming and outgoing InteractionFlows); if the parameter is held by a ViewContainer, it can be referenced within the ViewContainer itself, and within the contained ViewContainers, ViewComponents, and ViewComponentParts (plus the incoming and outgoing InteractionFlows).
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18918: actions in containers (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: ViewContainers cannot contain Actions. This should be possible.
Resolution: Add containment relation between ViewContainer and Action. In clause 8.1.3 figure and text have been updated.
Revised Text: In clause 8.1.3. Replaced Figure 7 with this: Added as last sentence in text: ViewContainers can contain ViewElements (namely other ViewContainers or ViewComponents) or Actions.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18919: module defs (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Critical
Summary: The spec misses the concept of ModuleDefinition, so one can use a module but not define it. Module definitions should come with a packaging mechanism too.
Resolution: Add ModuleDefinition and Module Package. Module renamed as ModuleDefinition (as a NamedElement); added Element, PortDefinition and ModulePackage in metamodel, with composite pattern. Added respective descriptions. Modules refer to ModuleDefinitions. Flows in PortDefinition can only be connected to elements within the ModuleDefinition. Flows in PortDefinition can only be connected to elements outside the Module. The set of Parameters of the Port is derived from the set of Parameters of the corresponding PortDefinition. Created new general clause for describing the new concepts and showing the metamodel fragment. Created all the specific clauses needed for describing the new concepts.
Revised Text: see page 24 of ptc/2014-03-13 for figure Created new Clause: 8.1.11 � Modularization Added figure of metamodel fragment describing the new modularization concepts: Figure 15: Modularization concepts in IFML Added respective descriptions in the new document Clause 8.1.11, as follows: IFML includes a set of concepts that help improving reuse and modularization of models. The main concept is ModuleDefinition, which allows the definition of an arbitrary piece of IFML model, which can be subsequently reused in models. ModuleDefinitions can be aggregated in a hierarchical structure of ModulePackages. ModuleDefinitions may comprise PortDefinitions. PortDefinitions represent interaction points with a Module. PortDefinitions hold Parameters, for transferring values to and from the ModuleDefinition. An input PortDefinition has outgoing InteractionFlows to the inside of the Module. An output PortDefinition has incoming InteractionFlows from the inside of the Module. Module is the concept that enables reuse of ModuleDefinitions. Module has a reference to the relevant ModuleDefinition and is associated with a set of Ports, which in turn reference the corresponding PortDefinitions. An input Port (i.e., a Port referencing an input PortDefinition) has incoming InteractionFlows from the outside of the Module, for receiving input Parameters. An output Port has outgoing InteractionFlows to the outside of the Module, for shipping output Parameters. Added specific sub-Clauses in Clause 8.3, with following descriptive texts: 8.3.33Class ModularizationElement Abstract: No Generalization: � InteractionFlowModelElement � NamedElement Description A ModularizationElement is an abstract concept that represents both ModulePackages and ModuleDefinitions. Association Ends � modulePackage [0..1]: ModulePackage - The ModulePackage containing the ModularizationElement 8.3.35Class ModuleDefinition Abstract: No Generalization: � ModularizationElement Description A ModuleDefinition is a fully functional collection of user InteractionFlowModelElements and their corresponding Actions, which may be reused for improving IFML model maintainability. ModuleDefinitions can be aggregated in a hierarchical structure of ModulePackages. ModuleDefinitions may comprise PortDefinitions. A ModuleDefinition receives Parameter values from outside and provides Parameter values to the outside. ModuleDefinitions exchange Parameters by mean of input and output PortDefinitions. InteractionFlowModelElements contained in a Module may not be shared or referenced by other Modules or by the main InteractionFlowModel. A ModuleDefinition may comprise a reference to a BPMN Activity (meaning that the Module implements that Activity). Reuse of ModuleDefinition is obtained by adding Modules referencing that ModuleDefinition in IFML models. Association Ends � inputPort [0..*]: PortDefinition - Ports that distributes InteractionFlows and Parameters coming into the Module. � interactionFlowModelElement [1..*]: InteractionFlowModelElement - InteractionFlowModelElements contained by the Module. � outputPort [0..*]: PortDefinition - Ports that collect the InteractionFlows and Parameters going out from the Module. � modules [0..*]: Module - The set of Modules that are defined in the IFML model and reference the current ModuleDefinition � activityConcept [0..1]: ActivityConcept - Reference to a process activity (e.g., a BPMN Activity). If present, the current module is describes the technical implementation of the process activity 8.3.36Class ModulePackage Abstract: No Generalization: � ModularizationElement Description A ModulePackage is a container of ModuleDefinitions. ModulePackages can be nested in arbitrarily deep hierarchical structure. Association Ends � modularizationElements [0..*]: ModularizationElement � Set of ModularizationElements contained in the current ModulePackage 8.3.43Class PortDefinition Abstract: No Generalization: � InteractionFlowElement Description PortDefinitions represent interaction points with a ModuleDefinition. They are defined within a ModuleDefinition. They hold Parameters, for transferring values to and from the ModuleDefinition. An input PortDefinition has outgoing InteractionFlows to the inside of the Module. An output PortDefinition has incoming InteractionFlows from the inside of the Module. Modules that reference a ModuleDefinition may comprise Ports, which in turn reference the corresponding PortDefinitions. Association Ends � ports [0..*] :Port - Set of Ports referencing the current PortDefinition in some Modules implementing the ModuleDefinition within which the current PortDefinition is defined Modified descriptive text of existing sub-Clauses in Clause 8.3: 8.3.34Class Module Abstract: No Generalization: � InteractionFlowModelElement � NamedElement Description A Module is a named reference to a ModuleDefinition, which allows reuse of the model part specified in the ModuleDefinition. Module has a reference to the relevant ModuleDefinition and may be associated with a set of Ports, which in turn reference the corresponding PortDefinitions. For every PortDefinition in the ModuleDefinition there shall be 0 or 1 Ports in each corresponding Module. An input Port (i.e., a Port referencing an input PortDefinition) has incoming InteractionFlows from the outside of the Module, for receiving input Parameters. An output Port has outgoing InteractionFlows to the outside of the Module, for shipping output Parameters. Constraints � onlyOnePortPerPortDefinition self.moduleDefinition.portDefinitions -> forAll(pd | pd.ports -> select(p|p.module = self) -> size() = 1) Association Ends � Port s[0..*]: Port - Ports that collect InteractionFlows and Parameters incoming or outgoing from the Module. � moduleDefinition [1] :ModuleDefinition - The ModuleDefinition that is instantiated by the current Module 8.3.42Class Port Abstract: No Generalization: � InteractionFlowElement Description A Port is an interaction point between a Module and the surrounding model within which it is defined. Module is associated with a set of Ports, which in turn reference the corresponding PortDefinitions. An input Port (i.e., a Port referencing an input PortDefinition) has incoming InteractionFlows from the outside of the Module, for receiving input Parameters. An output Port has outgoing InteractionFlows to the outside of the Module, for shipping output Parameters. Association Ends � portDefinition [1] :PortDefinition � Reference to the PortDefinition that defines the interface of the current Port � module [1] : Module - Module that contains the current Port
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18920: Default container (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: In ClassViewContainer: The property Default can be true only for containers within a XOR container. One and only one Default subcontainer must be defined for a XOR container. Consider the option of transforming Default into an association from XOR container to one of its subcontainers.
Resolution: Added OCL condition on ViewContainer and fixed describing text.
Revised Text: In clause 8.3.34 - ViewContainer: In isDefault, added: This attribute is relevant when this ViewContainer shares the same parent ViewContainer with other ViewContainers, and the parent ViewContainer has property isXOR = true. In isXOR, added: If true, the contained ViewContainers of this ViewContainer will be presented to the user only one at the time, as the user interacts with the system. One of the contained ViewContainers must have attribute isDefault = true.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18921: Add Window in table 1 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Add Window in the list of main concepts in Table 1.
Resolution: Added new row in Table 2 (not Table 1) with Window, respective symbol, description and example
Revised Text: New text in Table 2: Window - A ViewContainer rendered as a window. - An HTML page or a desktop window. Window symbol added in third column:
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18922: Modality in Table 1 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Modal and Modeless containers must be tagged as <<Window>> in Table 1.
Resolution: Resolution: Instead of adding tag Window, they must be stereotypes themselves
Revised Text: Symbols have been fixed by replacing [Modal] and [Modeless] with <<Modal>> and <<Modeless>> in all the figures of the specification document
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18923: add event type onLoad (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Add a new event type onLoad, applicable to containers and components.
Resolution: added onLoadEvent metaclass. Correspondingly, all the other catching events have been renamed by adding the �On� prefix in front. Specific events are discussed in Clause 8.1.6. Events, and therefore their discussion is removed from Clause 8.1.10 Specific Events and ViewComponents
Revised Text: Added new clause for OnLoadEvent: 8.4.9Class OnLoadEvent Abstract: No Generalization: � SystemEvent Description An OnLoadEvent is triggered by the system when a ViewElement is completely computed and rendered. Removed Text from Clause 8.1.10 Specific Events and ViewComponents. New text: 8.1.10 Specific ViewComponents IFML includes a basic set of extensions to the core elements that exemplify how IFML may be extended. List, Details and Form are specializations of ViewComponent (see 8.1.4). The List ViewComponent is used to display a list of DataBinding instances. When a List ViewComponent is associated with an Event, it means that each DataBinding instance displayed by the component may trigger that Event. The Event will in turn cause the passing of the parameter values mapped to the DataBinding instance to a target InteractionFlowElement. The Details ViewComponent is used to display detailed information of a DataBinding instance. When the Details ViewComponent is associated with an Event, the triggering of the Event will cause the passing of the Parameter values mapped to the DataBinding instance to a target InteractionFlowElement. The Form ViewComponent is used to display a form, which is composed of Fields that may display or capture content from the user. Fields have Slots that hold their value. When the Field is a SelectionField, its associated Slots contain the available selection options and the selected one. When the Field is a SimpleField, the Slot contains the Field value. A Slot value of a SimpleField and the Slots corresponding to the selected options of SelectionFields also behaves as Parameters in order to be passed to other ViewElements or Actions when an Event is triggered. Form ViewComponents have ValidationRules, which determine if a Field value is valid or not.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18924: Fix Figure 64 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Figure 64 contains a RED [H] tag. Make it black and add the stereotype <<Window>> to all the containers.
Resolution: This and other figures still contained colored elements. All figures have been transformed in black and white (with grayscale filling of ViewComponents and Modules).
Revised Text:
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18925: An List - fix typo (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Fix at page 88: An List --> A List
Resolution: typo corrected
Revised Text: A List
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18926: Action description (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Action Description (page 30): replace InteractionViewElement with InteractionFlowElement.
Resolution: Typo fixed and sentence specified better, for clarity reasons.
Revised Text: In clause 8.3.1 Class Action, the new text is: 8.3.1Class Action Abstract: No Generalization: � InteractionFlowElement � NamedElement Description An Action is an InteractionFlowElement that represents a piece of business logic triggered by an Event. Actions may reference behavior models describing the actual business logic to be performed. Actions may trigger different Events called ActionEvents as the result of business logic computation termination or the occurrence of exceptions. Actions may reside on the server or on the client side. If no ActionEvent (and corresponding outgoing flow) is specified, IFML assumes as default an ActionEvent and NavigationFlow that lead back to the ViewComponent or ViewContainer from which the navigation to the Action was launched. Constraints � actionsCannotCallActions self.actionEvent->forAll(e | e.navigationFlow->forAll(nf | not nf.targetInteractionFlowElement.oclIsTypeOf(IFML::Core::Action))) Association Ends � actionEvent [0..*]: ActionEvent - Events triggered by the Action. � dynamicBehavior [1]: DynamicBehavior � The business logic to be carried out by the Action. � viewContainer [0..1]: ViewContainer � The ViewContainer that contains the current Action.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18927: Menu ViewContainer (ifml-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Add a new viewcontainer called Menu in the metamodel, as an extension, together with Window. Peculiarity: only contains events, no sub-containers or components
Resolution: Menu class added as a specialization of ViewContainer, with OCL constraint and describing text.
Revised Text: New Clause added: 8.4.8Class Menu Abstract: No Generalization: � ViewContainer Description: A Menu is a special kind of ViewContainer used to model the concept of a menu of options in IFML. It cannot contain ViewComponents or sub-ViewContainers. Constraints � self.viewElements -> select(e | e.oclIsTypeOf(ViewContainer) or e.oclTypeOf(ViewComponent) ) -> isEmpty()
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18928: wrong component in figure 54 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: In Figure 54: Message Full Search viewcomponent must be replaced by <<Form>> Message Writer view component. The send event must be a submit event. Also fix the description of Figure 54 accordingly (and mention MessageWriter as a view container, not component)
Resolution: Figure fixed by replacing the <<Form>> component as requested. �Message Full Search� text in <<Form>> has been replaced with �Message Writer�. Send Event changed to Submit event. �Message Keyword Search� in <<Details>> replaced with �Message Details�. Caption of Figure 53 fixed: MessageReader ? MessageDetails
Revised Text: see page 40 of prc/2014-03-13
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18929: throwing events in examples (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: remove throwing events after each action in the examples of appendix A.3.
Resolution: Throwing events are left there because they have an important role. However, a more precise textual explanation has been written.
Revised Text: Text under figure 46 amended as: The execution of an action produces an action completion event and the sending of an asynchronous throwingEvent notification, denoted as a black circle reached by the outgoing InteractionFlow from the Action box. Such a notification throwing event is matched by a catching event, which triggers the display of a MessageNotification view component, shown in Figure 47.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18930: MessageWritter typo (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: MessageWritter appears in figure 56 and others. Replace with MessageWriter all over the document.
Resolution: MessageWritter has been replaced with MessageWriter in all the figures containing it.
Revised Text: Revised Text: �MessaggeWritter� replaced with ? �MessageWriter�
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18931: MessageReader in example (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Description of examples in pages 82-91 sometimes still mention the component MessageReader, while the correct label is Message Details. (also be sure to set all the names in italics format)
Resolution: Names of components in examples always shown in italics. MessageReader component references removed. Description of Figure 54 modified as below.
Revised Text: Revised Text: As shown in Figure 54, the selection of a message from the MessageList view component causes the MessageDetails view component to be displayed. Such a component permits the user to access one specific message at a time. The XOR MessageReader ViewContainer enables alternative visualization of the MessageDetails and MessageList ViewComponents
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18932: misplaced img (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: A misplaced image appears at the bottom of page 81 of the PDF version of the spec. Remove
Resolution: This was a problem in the generation of the PDF. The image has been anchored in the right position in the document, so misplacement disappears when the PDF is generated in the new version of the spec.
Revised Text:
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18933: parameter direction (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: the property "kind" of Parameter must be renamed as Direction. Direction of parameter is described as one of: direction ::= 'in' | 'out' | 'inout' and defaults to 'in' if omitted.
Resolution: Property kind changed to direction. ParameterKind enumeration changed to Direction. Direction values fixed as requested. Text in Clauses 8.1.5, 8.2.1 and 8.3.27 has been fixed.
Revised Text: In Clause 8.1.5 Parameters, text has been rewritten as: Parameters have a direction property, which can be input (in), output (out) or input-output (inout). Default direction is input. An input Parameter allows an InteractionFlowElement to receive one or more values through an incoming NavigationFlow or DataFlow. An output Parameter allows an InteractionFlowElement to expose one or more values through an outgoing NavigationFlow or DataFlow. An input-output Parameter allows for both behaviours. A ParameterBinding determines to which input Parameter of a target InteractionFlowElement an output Parameter of a source InteractionFlowElement is connected and thus how the parameter value will flow when an Event is triggered and the InteractionFlow is followed. ParameterBindings that flow together with an InteractionFlow are grouped by a ParameterBindingGroup, which in turn is related to the InteractionFlow. In Clause 8.3.27 Parameter, text has been rewritten as: Description A Parameter is a typed name, whose instances hold values. Parameters are held by InteractionFlowElements, i.e., ViewElements, ViewComponentParts, Ports, and Actions. Parameters flow between InteractionFlowElements when Events are triggered. Parameters may correspond to elements of the user interface (for instance, fields in a form), determining whether the element of the user interface is read-only or modifiable. Parameters have a direction property, which can be input (in), output (out) or input-output (inout). Default direction is input. The scope of a Parameter (i.e., the model space where it can be used or referenced) is the InteractionFlowElement that holds the Parameter, plus the incoming and outgoing InteractionFlows. This means that: if the parameter is held by a ViewComponent, it can be referenced only within the ViewComponent itself and the contained ViewComponentParts (plus the incoming and outgoing InteractionFlows); if the parameter is held by a ViewContainer, it can be referenced within the ViewContainer itself, and within the contained ViewContainers, ViewComponents, and ViewComponentParts (plus the incoming and outgoing InteractionFlows).Attributes � direction: Direction - Determines if the parameter direction is input, output or input-output. � defaultValue: Expression � default value of the parameter, calculated through the specified expression. In Clause 8.2.1 Enumeration Direction the description has been fixed as: Enumeration specifying the different possible directions of parameters. Literals � in (input): An input Parameter allows an InteractionFlowElement to receive one or more values through an incoming NavigationFlow or DataFlow � inout (input-output): An output Parameter allows an InteractionFlowElement to expose one or more values through an outgoing NavigationFlow or DataFlow. � out (output): A Parameter of kind input-output allows for both behaviours.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18934: parameters of field (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: The class field must have an association with parameter, to allow input and output of values from the field when it has no slots.
Resolution: Instead of defining an association between Field and Parameter, the class Field has been defined as extension of Parameter. In this way, a Field automatically acts as a parameter.
Revised Text: Clause 8.4.3. Field description has been fixed accordingly: 8.4.3Class Field Abstract: Yes Generalization: � ViewComponentPart � Parameter Description A Field is a value-type pair whose value may be displayed to the user or serves as a mean for capturing input from the user. Fields also behave as Parameters for passing their values to and from other InteractionFlowElements. There are two kinds of fields, SimpleFields and SelectionFields.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18935: Form class description (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: The description of Form class in section 8.4.4 is wrong (it is actually a definition of another class). Replace with correct definition.
Resolution: Fixed description of Form Class in Section 8.4.4
Revised Text: New description in Clause 8.4.4. Form: The Form ViewComponent represents input forms where user can submit information through Fields (SimpleFields or SelectionFields). It comprises at least one Field and typically at least one SubmitEvent
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18936: data access typo (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: In page 26, section 7.1.8, DataAccess (old term) must be replaced with DataBinding
Resolution: typo fixed. ContentAccess replaced with DataBinding in clause 8.1.8
Revised Text: Sentence in 8.1.8. becomes: A DataBinding is associated with a ConditionalExpression
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18937: ports in modules (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Min cardinality of relation Module--Port must be 0: a Module may have 0 Ports.
Resolution: fixed minimum cardinality for associations in the metamodel, both for Module/Port and ModuleDefinition/PortDefinition and text updated. Constraint onlyOnePortPerPortDefinition added for describing relation between Ports and PortDefinitions.
Revised Text: In Clause 8.3.34 Module: Module has a reference to the relevant ModuleDefinition and may be associated with a set of Ports, which in turn reference the corresponding PortDefinitions. For every PortDefinition in the ModuleDefinition there shall be 0 or 1 Ports in each corresponding Module. Constraints � onlyOnePortPerPortDefinition self.moduleDefinition.portDefinitions -> forAll(pd | pd.ports -> select(p|p.module = self) -> size() = 1) Association Ends � ports[0..*]: Port - Ports that collect InteractionFlows and Parameters incoming or outgoing from the Module. � ModuleDefinition [1]: ModuleDefinition � The ModuleDefinition that is instantiated by the current Module.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18938: symbol of submit event (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: The symbol of the submit event should be changed from simple big rightwards arrow ( ➡ ) to an arrow similar to the Return button in keyboards (↵ )
Resolution: The symbol of the event has been changed and all the figures where it was used updated accordingly.
Revised Text:
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18939: throwing and catching events (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Critical
Summary: Events should be subtyped by two specializations: throwing event and catching event, which allows explicit understanding of the role of the event. Corresponding icons should be designed (e.g., one negative and one positive, as in BPMN).
Resolution: added CatchingEvent and ThrowingEvent. Hierarchy of events restructured accordingly. Added the text clauses describing the new events. Event description has been modified as from below.
Revised Text: New Classes descriptions added: 8.3.6Class CatchingEvent Abstract: No Generalization: � Event Description A CatchingEvent is an occurrence that can affect the state of the application, by causing navigation and/or Parameter value passing between InteractionFlowElements. CatchingEvents may be produced by a user interaction (ViewElementEvent), by an action when it finishes its execution (ActionEvent), or by the system in the form of notifications (SystemEvent), or by a navigational jump (JumpEvent) in the model that reaches a LandingEvent. 8.3.37Class ThrowingEvent Abstract: No Generalization: � Event Description A ThrowingEvent is an occurrence of event that is generated by the modeled application. Event occurences generated by ThrowingEvent can be captured by CatchingEvents. Existing Classes descriptions updated: 8.3.17Class Event Abstract: No Generalization: � InteractionFlowElement Description An Event is an occurrence that can affect the state of the application. Events can be ThrowingEvent (events that are thrown by the modeled interaction) or CatchingEvent (events that are captured by the modeled interaction and used as triggers causing navigation and/or Parameter value passing between InteractionFlowElements. Constraints � onlyOneInAndOutFlow self.outInteractionFlow -> size() <= 1 and self.inInteractionFlow -> size() <= 1 Association Ends � activationExpression [0..1]: ActivationExpression - Reference to an ActivationExpression whose evaluation result determines if the Event is active or inactive. If no ActivationExpression is given, the default is that the Event is active. � interactionFlowExpression [0..1]: InteractionFlowExpression - InteractionFlowExpression determining the InteractionFlows to be followed after the occurrence of the Event. � navigationFlow [0..*]: NavigationFlow - NavigationFlows triggered by the Event.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18940: JUMP event type (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: A new event type should be added, for allowing direct jump from one place in the diagram to another.
Resolution:
Revised Text:
Actions taken:
September 17, 2013: received issue
Issue 18941: view components in examples (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Some view components in example images appear outside the containers (figs. 40, 43, 58). Add containers to avoid misunderstandings.
Resolution: Containers added to all images when needed
Revised Text: see pages 58/59 of ptc/2014-03-13 for details
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18942: connection to BPMN (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Modules should include a reference to a BPMN Activity (optional) to represent the fact that a module could implement a business activity.
Resolution: ModuleDefinition (not Module) now contains a reference to a BPMN Activity
Revised Text: Added text in 8.3.35 ModuleDefinition: A ModuleDefinition may comprise a reference to a BPMN Activity (meaning that the Module implements that Activity). Association Ends � activityConcept [0..1]: ActivityConcept � Reference to a process activity (e.g., a BPMN Activity). If present, the current module is describes the technical implementation of the process activity. [where ActivityConcept and BPMNActivityConcept are defined as: ] 8.3.4Class ActivityConcept Abstract: No Generalization: � NamedElement Description ActivityConcepts are an abstract concept describing the idea of business action that can be implemented through an IFML ModuleDefinition. Typical examples could be BPMN Activities or Activities in UML Activity Diagrams. Association Ends � moduleDefinition [1]: ModuleDefinition � The ModuleDefinition that implements the business process ActivityConcept. 8.3.9Class BPMNActivityConcept Abstract: No Generalization: � ActivityConcept Description BPMNActivityConcepts are a specialization of ActivityConcept for representing the particular case of BPMN Activities. Association Ends: � activity [1] : Activity � Reference to a BPMN Activity
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18943: actions (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Actions must have a Name property. They must also appear in the UML Profile.
Resolution: Action now is now also a specialization of a NamedElement. Action added in the UML Profile
Revised Text: In Clause 8.3.1 Action added generalization NamedElement 8.3.1Class Action Abstract: No Generalization: � InteractionFlowElement � NamedElement
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18944: modules in UML profile (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity: Critical
Summary: The Module concept is missing in the UML profile.
Resolution: Module has been added in the UML profile. Corresponding text fixed.
Revised Text: see pages 138 - 139 of ptc/2014-03-13 for details
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18945: extensibility (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Extensibility of the language should be made more explicit. The set of extensible concepts should be listed.
Resolution:
Revised Text: The following text has been added at the end of Section 7.3: Extensions are meant to refine the semantics of the core concepts or to provide specific cases of core concepts. As such, they must therefore refine the semantics of the IFML concepts, and not modify it. The following concepts (and their extensions) can be extended in IFML while still achieving compliance to the standard: � ViewContainer � ViewComponent � ViewComponentPart � Event � DomainConcept and FeatureConcept � BehaviorConcept and BehavioralFeatureConcept Extensions of other elements are not allowed.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 18946: content model (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: The supported content model is only UML. This should be generalized to any content model, and UML should be left as an example
Resolution: Added classes to the metamodel: FeatureConcept and DomainConcept, UMLStructuralFeature and UMLDomainConcept, BehavioralFeatureConcept and BehaviorConcept, UMLBehavioralFeature and UMLBehavior. Content can now be referenced through the FeatureConcept and DomainConcept classes. Behavior can now be referenced through the BehavioralFeatureConcept and BehaviorConcept classes. UML becomes one specific case of binding.
Revised Text: Figure 12 has been replaced with new figure: Descriptive text in Clause 8.1.8 has been fixed to cover the description of the new metaclasses as follows: 8.1.8Content Binding ViewComponents may retrieve content by means of the ContentBinding. ContentBinding represents any source of content. ContentBinding has as an optional attribute the URI of the resource from which the content may be obtained. ContentBinding is specialized in two concepts, DataBinding and DynamicBehavior. A DataBinding references a DomainConcept (for instance, a Classifier in UML) that may represent an object, an XML file, a table in a database etc. A DataBinding is associated with a ConditionalExpression, which determines the specific content to be obtained from the content source. A DynamicBehavior represents a content access or business logic such as a service or method that returns a result after an invocation, as represented by a BehavioralFeature or Behavior in UML. A DataBinding contains VisualizationAttributes used by ViewComponents to determine the features accessed from the DataBinding that may be shown to the user, such as a data base column or an XML element or attribute, as represented using UML StructuralFeatures. The following sub-clauses have been added in Clause 8.3: 8.3.5Class BehavioralConcept Abstract: No Generalization: � NamedElement Description BehaviorConcept represents the generic Behavior (for instance, a UML dynamic diagram) which can be referenced as DynamicBehavior in a ContentBinding. Association Ends � dynamicBehavior [0..1]: DynamicBehavior � Placeholder in a ContentBinding of the Behavior to be executed by the Action or ViewComponent. 8.3.6Class BehavioralFeatureConcept Abstract: No Generalization: � NamedElement Description BehavioralFeatureConcept represents the generic BehavioralFeature of a DomainModel element (for instance, a Class method) which can be referenced as DynamicBehavior in a ContentBinding. Association Ends � dynamicBehavior: DynamicBehavior � Placeholder in a ContentBinding of the BehavioralFeature to be executed by the Action or ViewComponent. 8.3.15Class DynamicBehavior Abstract: No Generalization: � ContentBinding Description DynamicBehavior represents the binding of the system with a service or operation, which may be invoked in order to carry out business logic or return content. Constraints � eitherBehavioralFeatureOrBehavior self.behavioralFeature -> notEmpty() xor self.behavior -> notEmpty() Association Ends � behavioralFeatureConcept [0..1]: behavioralFeatureConcept - BehavioralFeatureConcept representing a procedure, method, function etc, that may be invoked by a ViewComponent to carry out business logic or obtain content. � behaviorConcept [0..1]: BehaviorConcept - Representing a procedure, method, function etc, that may be invoked by a ViewComponent to carry out business logic or obtain content. 8.3.12Class DataBinding Generalization: � ContentBinding Description DataBinding represents the binding of the system with an instance of an element of the DomainModel such as a table, an object, an XML file etc. Association Ends � domainConcept [1]: domainConcept � A concept specifying the data structure to which the ViewComponent is bound, such as a UML class, a table in a relational data base or an XML file. � conditionalExpression [0..*]: ConditionalExpression - ConditionalExpressions that determine how to access the content. � visualizationAttribute [0..*]: VisualizationAttribute - VisualizationAttributes that determine the StructuralFeatures that should be shown to the user, such as a data base column or an XML element or attribute. � dataContextVariable [0..*]: DataContextVariable � reference to the ContextVariable that makes use of the DataBinding. 8.3.16Class DomainConcept Abstract: No Generalization: � NamedElement Description The DomainConcept represents a generic concept, class, entity of the DomainModel, which can be referenced in a DataBinding. Its purpose is to allow extensibility in terms of concepts from different modeling languages representing the DomainModel. Association Ends � dataBinding [0..1]: DataBinding - Reference to the DataBinding in a ViewComponent that uses the current DomainConcept. 8.3.42Class UMLBehavior Abstract: No Generalization: � BehaviorConcept Description UMLBehavior represents a Behavior specified in UML (that is, a UML dynamic diagram) which can be referenced as DynamicBehavior in a ContentBinding. Association Ends � behavior [0..1]: UML::Behavior � UML Behavior to be executed by the Action or ViewComponent. 8.3.43Class UMLBehavioralFeature Abstract: No Generalization: � BehavioralFeatureConcept Description UMLBehavioralFeature represents a BehavioralFeature specified in UML (typically, a UML method in a Class) which can be referenced as DynamicBehavior in a ContentBinding. Association Ends � behavioralFeature [0..1]: UML::BehavioralFeature � UML BehavioralFeature to be executed by the Action or ViewComponent. 8.3.44Class UMLStructuralFeature Abstract: No Generalization: � FeatureConcept Description The UMLStructuralFeature is a specific FeatureConcept referring to a UML StructuralFeature. Association Ends � structuralFeature [0..1]: UML::StructuralFeature - Reference to the UML element of the DomainModel. 8.3.45Class UMLDomainConcept Abstract: No Generalization: � DomainConcept Description The UMLDomainConcept is a specific DomainConcept referring to a UML Classifier. Association Ends � classifier [0..1]: UML::Classifier - Reference to the UML Classifier of the DomainModel that will be connected to a ViewElement through a DataBinding.
Actions taken:
September 17, 2013: received issue
July 15, 2014: closed issue
Issue 19040: Rename submit and select events (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Rename submit and select events Call them OnSubmit and OnSelect
Resolution: SubmitEvent and SelectEvent have been renamed as OnSubmitEvent and OnSelectEvent. Names have been replaced in the metamodel and in the text.
Revised Text: Figure 10 has been replaced by a new version including the new names of the events (see highlighted classes): Third sentence of clause 8.1.6 Events has been rewritten as: There are three types of CatchingEvents: ViewElementEvents, resulting from a user interaction (with specific subtypes OnSelectEvent and OnSubmitEvent), ActionEvents and SystemEvents (such as OnLoadEvent). see page 69 of ptc/2014-03-13 for details
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19041: Add Default value to parameters (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Add Default value to input parameters. It can be an OCL expression?
Resolution: new attribute defaultValue (of type IFML::Core::Expressoin) added to Parameter
Revised Text: see page 71 of ptc/2014-03-13 for details
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19042: An event can have at most one incoming and one outgoing flow (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: An event can have at most one incoming and one outgoing flow
Resolution: Ocl constraint added to the Event metaclass
Revised Text: Constraint added in Clause 8.3.24 Class Event Constraints � onlyOneInAndOutFlow self.outInteractionFlow -> size() <= 1 and self.inInteractionFlow -> size() <= 1
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19043: Add SetContext event (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Add SetContext event
Resolution: SetContextEvent added for describing the happening of the setting of a ContextVariable value.
Revised Text: New clause added: 8.4.16Class SetContextEvent Abstract: No Generalization: � ThrowingEvent Description A SetContextEvent is launched every time a ContextVariable is set or assigned a new value.
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19044: context variables (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Critical
Summary: Context: context variables are pointers to the corresponding element in the data model.
Resolution: Added ContextVariable, SimpleContextVariable, and DataContextVariable metaclasses and respective descriptions.
Revised Text: In Clause 8.3.14 Class Context, last sentence modified as: Context is composed of one or more ContextDimensions and may comprise ContextVariables. And added new association end: � contextVariables [0..*]: ContextVariable � set of ContextVariables whose values are relevant for the current Context. Added new Clauses as follows: 8.3.16Class ContextVariable Abstract: No Generalization: � NamedElement Description ContextVariable is a name-value pair that allows to store information associated to the current Context. It can be a SimpleContextVariable, storing a primitive type value, or a DataContextVariable, referencing a DataBinding. Attributes � scope : ContextVariableScope � scope of the ContextVariable. Association Ends � context [1] : Context � Context within which the ContextVariable is relevant. 8.3.18Class DataContextVariable Abstract: No Generalization: � ContextVariable Description DataContextVariable allows to associate a DataBinding to the current Context. Association Ends � dataBinding [1]: DataBinding - Reference to the DomainModel concept used as ContextVariable. 8.3.44 Class SimpleContextVariable Abstract: No Generalization: � ValueSpecification Description SimpleContextVariable is a typed name-value pair that can be associated to the current Context. Allowed types are the primitive ones. 8.2.2Enumeration ContextVariableScope Description Enumeration specifying the different scope levels for ContextVariables.Literals � ApplicationScope: Scope of the ContextVariable is the application � SessionScope: Scope of the ContextVariable is the user session � ViewContainerScope: Scope of the ContextVariable is the ViewContainer (for instance, the Web page or the window) Added new association end in Clause 8.3.17 DataBinding: � dataContextVariable [0..*]: DataContextVariable � reference to the ContextVariable that makes use of the DataBinding. Figure 13 replaced with this one: Added new sentence at the end of Clause 8.1.9 Context: ContextVariables can be associated to the Context to store primitive values (SimpleContextVariable) or objects (DataContextVariable) that store the state of the system in the current context.
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19045: Outgoing flows from actionevents (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Outgoing flows from actionevents can only end in viewcomponents o viewcontainers
Resolution:
Revised Text:
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Discussion: Not needed. An ocl constraint already exists in Class Action: � actionsCannotCallActions self.actionEvent->forAll(e | e.navigationFlow->forAll(nf | not nf.targetInteractionFlowElement.oclIsTypeOf(IFML::Core::Action))) Disposition: Closed, no change
Issue 19046: Dangling actions (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Define that dangling actions by default return back to the container containing the starting component (in Action sections)
Resolution: Added appropriate text in description of Class Action. Removed ActionEventType from SystemEventType
Revised Text: In Clause 8.3.1. Class Action, descriptive text extended as follows: An Action is an InteractionFlowElement that represents a piece of business logic triggered by an Event. Actions may reference behavior models describing the actual business logic to be performed. Actions may trigger different Events called ActionEvents as the result of business logic computation termination or the occurrence of exceptions. Actions may reside on the server or on the client side. If no ActionEvent (and corresponding outgoing flow) is specified, IFML assumes as default an ActionEvent and NavigationFlow that lead back to the ViewComponent or ViewContainer from which the navigation to the Action was launched.
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19047: Fig. 53 and all others that include a XOR (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Fig. 53 and all others that include a XOR: add a ʺ...ʺ for showing that there are more elements in the xor
Resolution: Figures have been fixed by adding ���
Revised Text: see pages 78 - 79 of ptc/2014-03-13 for details
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19048: History and default context are not defined (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: In these sentences (9.3): ʺIf the computation semantics of the ViewContainer is without history, default contexts are considered in point 3. if the computation semantics is with context history, components may draw their input values either from default contexts or from the past context existing prior to the last flow navigation.ʺ history and default context are not defined. Simplify this part.
Resolution: Disposition: See issue 16162 for disposition
Revised Text:
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19049: parameterBinding [0..*] (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: parameterBinding [0..*]: ParameterBinding - The ParameterBindings composing the ParameterBindingGroup.(8.3.29) should be 1..*
Resolution: Multiplicity of association (and plural name of association) fixed.
Revised Text: Association end in Clause 8.3.41 ParameterBindingGroup fixed as: � parameterBindings [1..*]: ParameterBinding - The ParameterBindings composing the ParameterBindingGroup.
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19050: triggeringExpression [1..*] (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: "triggeringExpression [1..*]: Expression - Expressions that determines when or under what conditions the SystemEvent should be triggered." (8.3.31) should be 0..*
Resolution: Multiplicity of association fixed.
Revised Text: Revised Text: Multiplicity of association fixed in Clause 8.3.45 SystemEvent: � triggeringExpression [0..*]: Expression - Expressions that determines when or under what conditions the SystemEvent should be triggered.
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19051: system event (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: system event: chech difference between activation expression, triggering expression, interactionflow expression
Resolution: The three concepts have different meaning. No action required in the specification. Disposition: Closed, no change
Revised Text:
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19052: Description of some association ends (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Description of some association ends is missing and not listed
Resolution: all the lists of association ends, attributes and ocl constraints have been checked. Missing elements added throughout the spec. Association ends names have been set to plural (adding �s�) when maximum multiplicity is bigger than 1. Fixes applied throughout the specification and the metamodel
Revised Text: In Clause 8.3.1Class Action added s to actionEvent: � actionEvents [0..*]: ActionEvent - Events triggered by the Action. In Clause 8.3.1Class Action added association end � viewContainer [0..1]: ViewContainer � The ViewContainer that contains the current Action. In Clause 8.3.14Class Context added s to ContextDimension: � contextDimensions [0..*]: ContextDimension - ContextDimensions the user context must satisfy to have access to one or more Viewpoints. In Clause 8.3.14Class Context added association end: � contextVariables [0..*]: ContextVariable � set of ContextVariables whose values are relevant for the current Context. In Clause 8.3.17Class DataBinding added association end: � dataContextVariables [0..*]: DataContextVariable � reference to the ContextVariable that makes use of the DataBinding. In Clause 8.3.17Class DataBinding added s to ConditionalExpression and VisualizationAttribute: � conditionalExpressions [0..*]: ConditionalExpression - ConditionalExpressions that determine how to access the content. � visualizationAttributes [0..*]: VisualizationAttribute - VisualizationAttributes that determine the StructuralFeatures that should be shown to the user, such as a data base column or an XML element or attribute. In Clause 8.3.23Class Element added s to annotation and constraint: � annotations [0..*]: Annotation - Annotations, comments, tags, etc., owned by the Element. � constraints [0..*]: Constraint - Constraints applied to the Element. In Clause 8.3.24Class Event added association end: � navigationFlows [0..*]: NavigationFlow - NavigationFlows triggered by the Event. In Clause 8.3.27Class IFMLModel added s to interactionFlowModelViewpoint: � interactionFlowModelViewpoints [0..*]: Viewpoint - Viewpoints of the InteractionFlowModel. In Clause 8.3.29Class InteractionFlowElement added s to inInteractionFlow, outInteractionFlow and parameters: � inInteractionFlows [0..*]: InteractionFlow - Incoming InteractionFlows. � outInteractionFlows [0..*]: InteractionFlow - Outgoing InteractionFlows. � parameters [0..*]: Parameter - Parameters contained by the InteractionFlowElement. In Clause 8.3.30Class InteractionFlowExpression added s to interactionFlow: � interactionFlows [2..*]: InteractionFlow - InteractionsFlows for which the expression is evaluated. In Clause 8.3.31Class InteractionFlowModel added s to interactionFlowModelElement: � interactionFlowModelElements [0..*]: InteractionFlowModelElement - Elements of the InteractionFlowModel. In Clause 8.3.35Class ModuleDefinition added association ends: � inputPorts [01..*]: PortDefinition - Ports that collectdistributes InteractionFlows and Parameters coming into the Module. � interactionFlowModelElements [1..*]: InteractionFlowModelElement - InteractionFlowModelElements contained by the Module. � outputPorts [01..*]: PortDefinition - Ports that collect the InteractionFlows and Parameters going out from the Module. � modules [0..* ]: Module � T he set of Modules that are defined in the IFML model and reference the current ModuleDefinition. In Clause 8.3.41Class ParameterBindingGroup added s to parameterBinding: � parameterBindings [10..*]: ParameterBinding - The ParameterBindings composing the ParameterBindingGroup. In Clause 8.3.42Class Port added association ends: � PortDefinition [1] : PortDefinition � Reference to the PortDefinition that defines the interface of the current Port � module [1] : Module - Module that contains the current Port In Clause 8.3.45Class SystemEvent added s to triggeringExpression: � triggeringExpressions [01..*]: Expression - Expressions that determines when or under what conditions the SystemEvent should be triggered. In Clause 8.3.51Class ViewComponent added s to viewComponentPart: � viewComponentParts [0..*]: ViewComponentPart - Parts of the ViewComponent. In Clause 8.3.52Class ViewComponentPart added s to subViewComponentPart and viewElementEvent: � subViewComponentParts [0..*]: ViewComponentPart - Nested ViewComponentParts. � viewElementEvents [0..*]: ViewElementEvent - Events that this ViewComponentPart may trigger. In Clause 8.3.53Class ViewContainer added s to viewElement: � viewElements [0..*]: ViewElement - The ViewElements owned by the ViewContainer. In Clause 8.3.53Class ViewContainer added association end: � actions [0..*]: Action � TEXTThe Actions owned by the ViewContainer. In Clause 8.3.54Class ViewElement added s to viewElementEvent: � viewElementEvents [0..*]: ViewElementEvent - ViewElementEvents contained by the ViewElement. In Clause 8.3.56Class Viewpoint added s to interactionFlowModelElement: � interactionFlowModelElements [0..*]: InteractionFlowModelElement - InteractionFlowModelElements that build up this Viewpoint. In Clause 8.4.5Class List added association end: � selectEvents [0..*]: OnSelectEvent - Events that represent the selection of a DataBinding instance of the List ViewComponent and the passing of the value as a Parameter. In Clause 10.5.2Class IFMLCompartment added s to ownedLabel and ownedNode: � ownedLabels [0..*]: IFMLLabel - Composite association to the IFMLLabels owned by the compartment. � ownedNodes [0..*]: IFMLNode - Composite association to the IFMLNodes owned by the compartment. In Clause 10.5.4Class IFMLDiagram added s to diagramElement: � diagramElements [0..*]: IFMLDiagramElement � The diagram elements contained in this diagram. In Clause 10.5.5Class IFMLDiagramElement added s to ownedElement: � ownedElements [0..*]: IFMLDiagramElement - Composite association to the IFMLDiagramElements owned by the current IFMLDiagramElement. In Clause 10.5.7Class IFMLNode added s to ownedCompartment and ownedNode: � ownedCompartments [0..*]: IFMLCompartment - Composite associations to the IFMLCompartments owned by the node. � ownedNode [0..*]: IFMLNode - Nested nodes of the current node. This relation is only valid if the nested node is fixed to the parent node side. In Clause 8.3.14 Class Context added association end: � contextVariables [0..*]: ContextVariable � set of ContextVariables whose values are relevant for the current Context.
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19053: isLandmark (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: "� isLandmark: Boolean - If true, the ViewContainer is directly reachable from any ViewElement. It represents an implicit link between all the other ViewElements and the ViewContainer."[8.3.34] -- > replace: from any ViewElement contained, directly or indirectly, in the same ViewContainer
Resolution: proposed text change applied
Revised Text: In 8.3.51 Class ViewContainer, description of isLandmark property rewritten as: isLandmark: Boolean - If true, the ViewContainer is directly reachable from any ViewElement from any ViewElement contained, directly or indirectly, in the same ViewContainer. It represents an implicit link between all the other ViewElements and the ViewContainer.
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19054: viewelementevent cannot be associated with viewcomponentpart (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: viewelementevent cannot be associated with viewcomponentpart, is it correct?
Resolution: The association ViewComponentPart � ViewElementEvent already exists. However, it is not shown in any high level metamodel picture. Now added in Figure 10. Events.
Revised Text: see page 86 of ptc/2014-03-13 for details
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19055: ViewComponentPart: association with interactionflow is missing (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: ViewComponentPart: association with interactionflow is missing. Correct?
Resolution: It�s correct. ViewComponentPart inherits the association from InteractionFlowElement. No action needed. Disposition: Closed, no change
Revised Text:
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19056: Conditional expression can have outgoing flow (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Conditional expression can have outgoing flow. Correct? The text says it only supports incoming flows. Constraint missing?
Resolution: A conditional expression should not have an outgoing flow. The issue is closed Disposition: Closed, no change
Revised Text:
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19057: viewelementevent can be associated with 0..1 viewelements (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: viewelementevent can be associated with 0..1 viewelements. should be 1
Resolution: ViewElementEvent can be associated with 1 ViewElement. Metamodel and textual descriptions updated accordingly.
Revised Text: Association Ends of ViewElementEvent clause (8.3.56) fixed as: � viewElement [1]: ViewElement � ViewElement owning the ViewElementEvent.
Actions taken:
October 30, 2013: received issue
July 15, 2014: closed issue
Issue 19058: rewrite In ConditionalExpression (8.3.6) (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: In ConditionalExpression (8.3.6): rewrite the following: When a ConditionalExpression has an incoming NavigationFlow it means that the DataBinding is queried with the query expression represented by the ConditionalExpression for retrieving content.
Resolution: The wording of the description has been changed as follows
Revised Text: The wording of the description in clause 8.3.9 Class ConditionalExpression is now: Abstract: No Generalization: � Expression � ViewComponentPart Description A ConditionalExpression is a predefined query expression associated with a DataBinding. When a ConditionalExpression is present, the DataBinding is queried by applying the query in the ConditionalExpression for retrieving content.
Actions taken:
October 31, 2013: received issue
July 15, 2014: closed issue
Issue 19059: Replace ContentAccess with DataBinding (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: "ContentBinding is specialized in two concepts, DataBinding and DynamicBehavior. A DataBinding references a UML Classifier that may represent an object, an XML file, a table in a database etc. A **ContentAccess** is associated with a ConditionalExpression, which determines the specific content to be obtained from the content source. A DynamicBehavior represents a content access such as a service or method that returns content after an invocation, as represented by a UMLBehavioralFeature for representing it." (8.1.8) **ContentAccess** -- replace with DataBinding
Resolution: Disposition: See issue 18936 for disposition
Revised Text:
Actions taken:
October 31, 2013: received issue
July 15, 2014: closed issue
Issue 19064: Change content-model in domain-model (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Change content-model in domain-model rename in domain-model
Resolution: ContentModel has been renamed as DomainModel throughout the whole specification document and machine-readable files. Content Model has been replaced with Domain Model (matching the needed case) throughout the whole specification document.
Revised Text: Revised Text: ContentModel replaced by DomainModel. Content model replaced by Domain model.
Actions taken:
November 5, 2013: received issue
July 15, 2014: closed issue
Issue 19065: Class Form - wrong description text (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Replace: Order in which the ValidationRules are going to be applied to the Fields of the ViewComponent. with correct description (8.4.4)
Resolution: Disposition: See issue 19158 for disposition
Revised Text:
Actions taken:
November 5, 2013: received issue
July 15, 2014: closed issue
Issue 19066: Wrong associations in Class Form (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: (8.4.4) submitEvent [0..1]: SubmitEvent - Event that triggers a navigation, which passes the Field's values as Parameters to the target InteractionFlowElement. --> revise text. multiplicity is max N
Resolution: submitEvent association completely removed, to address issue 19160. No change needed for this issue. Disposition: Closed, no change
Revised Text:
Actions taken:
November 5, 2013: received issue
July 15, 2014: closed issue
Issue 19150: Section 1: scope (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: scope not well described Solution: Remove: "; and the distribution of control, data and business logic at the different tiers of the architecture" - not explicitly covered. Add the fact we are only referencing the business logic and not controlling the sequence of actions
Resolution: new text formulation, according to suggestion
Revised Text: In Section 1, Scope, the description of the scope is now: This specification defines the Interaction Flow Modeling Language (IFML). The objective of IFML is to provide system architects, software engineers, and software developers with tools for the definition of Interaction Flow Models that describe the principal dimensions of an application front-end: the view part of the application, made of view containers and view components; the objects that embody the state of the application and the references to business logic actions that can be executed; the binding of view components to data objects and events; the control logic that determines the actions to be executed after an event occurrence; and the distribution of control, data and business logic at the different tiers of the architecture. Added �view� to containers, and �references to� to business logic. Removed �sequence of� from actions (as IFML does not allow to specify orchestrations of actions).
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19151: Section 6.4: acknowledgements (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: authors list does not reflect contribution Solution: Put Brambilla, Fraternali first as main contributors
Resolution: Applied suggestion. Added Andrea Mauri as further author as he contributed to the finalization work.
Revised Text: Text in Section 6.4 Acknowledgements is now: The standardization initiative and the FTF of IFML are lead by Marco Brambilla. This specification was originally authored by: � Marco Brambilla (WebRatio and Politecnico di Milano) � Piero Fraternali (WebRatio and Politecnico di Milano) Other authors that contributed to the current version include: � Aldo Bongio (WebRatio) � Stefano Butti (WebRatio) � Adriano Comai (Soluta.net and WebRatio) � Wolfgang Kling (Ecole des Mines de Nantes and WebRatio) � Andrea Mauri (WebRatio and Politecnico di Milano) � Emanuele Molteni (WebRatio) � Ed Seidewitz (Model Driven Solutions) We wish to thank all the other contributors that provided useful input, feedback and discussions on the IFML specification.
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19152: Section 8.1.4: (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Section 8.1.4: Issue: Rephrase unclear sentence: "This new window may be a modal blocking interaction in all other previously active containers"
Resolution: sentence rephrased as below
Revised Text: In Clause 8.1.4. View Elements: - Removed part of first sentence of second paragraph: , and may be opened in a new window - Rephrased last part of third paragraph: This new window may be �modal�. Modal windows are meant to block any user interaction in all other previously active containers, until the new window is closed. Another special kind of ViewContainer is the Menu. Menus represent sets of interactive buttons or links that lead to some target container. Menus cannot contain subcontainers or ViewComponents.
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Discussion:
Issue 19153: Section 8.1.7 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Section 8.1.7 Issue: "The Expression's context is any IFML element denoted by Element. The Expression values"- Rewrite. Solution: Replace with: "The values". And add: "ConditionalExpressions can be defined only inside a DataBinding ViewComponentPart."
Resolution: Text rephrased as below
Revised Text: In Clause 8.1.7. Expressions: - added sentence at the end of fourth paragraph: ConditionalExpressions can be defined only inside a DataBinding ViewComponentPart. - removed sentence at the beginning of sixth paragraph: The Expression's context is any IFML element denoted by Element. The Expression - removed in the same sentence: (scope) The sentence now reads as: The values used to evaluate the expressions are defined depending on the specific Expression type.
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Discussion:
Issue 19154: Section 8.1.6 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Section 8.1.6 Issue: the URI attribute of ContentBinding must be optional
Resolution: The affected Clause is 8.1.8, not 8.1.6. Added �optional� in the textual description and optionality in the metamodel diagram (figure 12).
Revised Text: Phrase in Clause 8.1.8 now reads as: ContentBinding has as an optional attribute the URI of the resource from which the content may be obtained.
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19155: Section 8.3.24: (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Section 8.3.24: Issue: Remove the following miselading sentence: Modules may be replaced by other InteractionFlowElements with the same input and output Parameters.
Resolution: Sentence removed
Revised Text: The sentence above, formerly included in the Module clause (8.3.24) has been removed (from current section 8.3.35, ModuleDefinition).
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19156: Section 8.3.27: (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: add description of behaviour of data flows related to navigation flows
Resolution: Issue actually applies to section 8.3.26. New text added, both in section 8.3.26 and also in 8.3.13 to make DataFlow description compatible with the new description
Revised Text: In section 8.3.26 [Class NavigationFlow]: added When a NavigationFlow is triggered, a corresponding set of DataFlows may be triggered too, at the purpose of carrying parameters to the same or to other target InteractionFlowElements. The DataFlows that are triggered are all the ones having some parameter values available as an effect of the last interface status change. In section 8.3.13 [Class Dataflow]: rephrased definition as A DataFlow is a kind of InteractionFlow used for passing information between InteractionFlowElements. DataFlows imply Parameter passing but no navigation. DataFlows are triggered any time a parameter is available in output from the source InteractionFlowElement and transfer the Parameter values to the target InteractionFlowElement. The target of a DataFlow cannot be an Event.
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Discussion:
Issue 19157: Section 8.3.28 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: Parameters in parameterBinding must be characterized as input or output. (in text and metamodel)
Resolution: Fixed text and metamodel by characterizing parameters as input or output, through the attribute direction
Revised Text: Description of Section 8.3.40 ParameterBinding rephrased as: ParameterBinding connects an output Parameter of a source InteractionFlowElement with an input Parameter of a target InteractionFlowElement. Association Ends � sourceParameter [1]: Parameter � Output Parameter of the source InteractionFlowElement that participates in the ParameterBinding � targetParameter [1]: Parameter � Input Parameter of the target InteractionFlowElement that participates in the ParameterBinding Figure 9 replaced by: Disposition: Resolved
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19158: Section 8.4.4: (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: Text description of Form is incomplete
Resolution: New text describing the form added.
Revised Text: Description in Clause 8.4.4. Form is now: The Form ViewComponent is used to display one or more input fields in the user interface, so as to enable data entry by the user. A form comprises one or more ViewComponentParts, tagged with the Field stereotype. [PARTLY SUPERSEDED BY ISSUE 18935]
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19159: Section 8.3.32 - 8.3.33: (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: lists of ViewComponentParts and SubViewComponentParts
Resolution: added �a� in text of 8.3.33. The rest of the issue does not apply.
Revised Text: Sentence in 8.3.33 [Class ViewComponentPart] fixed as: A ViewComponentPart is an InteractionFlowElement that may not live outside the context of a ViewComponent.
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19160: Section 8.4.4: SubmitEvent property must be removed in text (not there in metamodel) (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: ISSUE 11: Section 8.4.4: Issue: SubmitEvent property must be removed in text (not there in metamodel)
Resolution: Association end removed from text
Revised Text: �Association ends� text and specific association end removed from Clause 8.4.4. Class Form. Removed text: Association ends � submitEvent [0..1]: SubmitEvent - Event that triggers a navigation, which passes the Field's values as Parameters to the target InteractionFlowElement.
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Discussion:
Issue 19161: Section 8.4.9: (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: SimpleField expose automatically an output parameter. Slots expose an input parameter. Solution: say that in the metamodel. Make simpleField and Slot inherit from Parameter and add OCL expressions? Rephrase Slot definition
Resolution: This applies to 8.4.10 (slot) and 8.4.3 (field). Slot description has been rewritten in 8.4.10. Slot now inherits from Parameter too. Field now inherits from Parameter too
Revised Text: Text regarding association with Parameter in Clause 8.4.3 Class Field has been fixed as: Fields also behave as Parameters for passing or receiving their values to other InteractionFlowElements. Description in Clause 8.4.10 Class Slot has been changed as: A Slot is a value placeholder for a Field. They are used for preloading information into the Field. When the Field is a SimpleField, the Slot contains the Field value. When the Field is a SelectionField, its associated Slots contain the available selection options. The provenance of the preloaded content is specified through a contained ViewComponentPart defining the ContentBinding. A Slots also act as Parameters in order to pass the contained information to other ViewElements or Actions when an Event is triggered. (and association ends removed)
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19162: Section 9.2 - 9.3: (ifml-ftf)
Click here for this issue's archive.
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
Issue 19163: Section 11.3 (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity: Critical
Summary: Figure 29 and figure 32: the nested component notation does not mean packaging but component realization. Fix figure and UML Profile structure. ViewComponents can be classes and not components. Nested component instances, on the other hand, mean composite structure, which is neither component packaging nor component realization!
Resolution: The figures derive from the definition of most of the IFML concepts as stereotypes of the UML Component class. The definition of the profile has been updated to fix this problem, as from resolution of issue 19164. The whole clause 11.3 has been restructured by using classes instead of components for defining ViewComponents. Furthermore, events have been stereotyped from UML Ports. Figures and respective descriptions have been fixed.
Revised Text: see pages 109 - 111 of ptc/2014-03-13 for details
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19164: Chapter 11: (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity: Critical
Summary: Issue: UML profile: reorganize viewelement UML profile correspondance as classes and components.
Resolution: At the purpose of solving implementability and semantics problems, some stereotypes have been redefined (from UML component to class). Furthermore, new stereotypes have been added for the new elements added in the metamodel for addressing the issues filed on IFML Beta 1, and respective descriptions and symbols have been added too
Revised Text: see pages 112 - 132 of ptc/2014-03-13 for details
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Discussion:
Issue 19165: Section 6.3: (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: Remove: The IFML textual syntax offers a textual syntax for expressing IFML models alternative, but equivalent, to the visual syntax
Resolution: Text above removed from Clause 6.3 � IFML artfacts. The reason is that IFML does not specify any textual syntax
Revised Text: Removed the following text from Clause 6.3: The IFML textual syntax offers a textual syntax for expressing IFML models alternative, but equivalent, to the visual syntax
Actions taken:
December 9, 2013: received issue
July 15, 2014: closed issue
Issue 19180: Low resolution images in specification (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: most images in the spec document are difficult to read, due to low resolution exporting problems. Solution: if possible, replace images with vector versions
Resolution: Diagram images have been replaced with vector graphics diagram images where possible. (note: this doesn�t change the content of the images, just the quality of the printing)
Revised Text: Images replaced throughout the specs document (with no impact on their content).
Actions taken:
January 14, 2014: received issue
July 15, 2014: closed issue
Issue 19195: Figure 3 - wrong diagram (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: iagram in Fig. 3 is wrongly repeating the Albums containers twice. It should appear only once, and the arrow should go back to it after exiting from the Action.
Resolution: Figure fixed as requested
Revised Text: see page 108 of ptc/2014-03-13 for details
Actions taken:
January 28, 2014: received issue
July 15, 2014: closed issue
Issue 19200: Class Expression description to be fixed (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Clarification
Severity: Minor
Summary: reference to the context in the descriptive text to be removed. Replace a "." with a "," in first sentence. In the metamodel, remove the association with Parameter [0..1].
Resolution: Text fixed as requested and as reported below. Metamodel fixed by removing association with Parameter
Revised Text: Text removed in Description of Clause 8.3.25. Class Expression: , in a given context, . replaced with , Association End to Parameter removed.
Actions taken:
January 30, 2014: received issue
July 15, 2014: closed issue
Issue 19203: DI and DD specifications need to be fixed based on the changes to the MM (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: Update definition of diagrams by adding the new concepts and fixing the updated ones. Replace: "actionExpression:" --> "activationExpression:" In listing of 10.6 remove rules for [modal] and [modeless], and for [clientSide]; Fix radius of the event element to static value. Add port and throwing events
Resolution:
Revised Text: see pages 134 - 137 of ptc/2014-03-13 for details
Actions taken:
January 31, 2014: received issue
July 15, 2014: closed issue
Issue 19206: Fig. 5 - ContentModel references UML Element (ifml-ftf)
Click here for this issue's archive.
Source: WebRatio Inc (Dr. Marco Brambilla, marco.brambilla(at)webratio.com)
Nature: Revision
Severity: Minor
Summary: The content model (aka Domain Model) should reference a generic modeling element (e.g., DomainElement), so as to enable any kind of domain model to be used with IFML. UML element can be associated to it. DomainElement should be extensible.
Resolution: Created new class in IFML Metamodel: DomainElement. All the classes describing the domain elements (DomainConcept, FeatureConcept, BehavioralFeatureConcept, BehaviorConcept) now extend the DomainElement class, instead of NamedElement. Association from DomainModel is to DomainElements and not to UML::Element. Fixed Figure 5 by adding the new DomainElement class and its 4 subclasses. Added new clause describing the DomainElement. Fixed generalization text in the 4 subclasses.
Revised Text: see pages 142 - 145 of ptc/2014-03-13 for details
Actions taken:
February 6, 2014: received issue
July 15, 2014: closed issue