ISO IEC 23007-1:2010 pdf – lnformation technology — Rich mediauser interfaces 一 Part 1: Widgets.
7.3 WIdget communication
7.3.1 OvervIew
As regular scenes, widgets may communicate with any external entities using communications means supporled by the presentation engine (e.g. Web servers and XMLHttpRequest object [2J: or streaming server and the RTSP protocol 131). However, the widget manager offers means for widgets to communicate with entities for which URL are not known at widget authoring time nor at widget delivery time but when the widget enters the active state. This is the case of widgets communicating with devices in a home network (e.g. UPnP media server [41) or the case of widgets communicating with local resources (e.g. battery status) or the case of widgets communicating with other widgets running in the same widget manager. For that purpose, widget authors may use the HFGwidget script interface defined in Clause 9 to determine the ad&ess of the linked external communication entity.
In this Part of ISO/IEC 23007, we assume that the type of each communication entity (external or internal), or of its services (remote or local), can be identified by a unique string (e.g. using URN) and that a description of the communication capabilities of that entity Is available. This description lists the messages that the entity can emit or receive, Each message has a name and a list of parameters. Each parameter carries a value and is identified by a name.
7.3.2 Matching services and Interfaces
The widget manager shall match the available servces with the interfaces of the activated widgets. This matching process is nomiatrve and may happen at any time, possibly at multiple times, when the widget is active. The matching process is as follows.
NOTE The widget manager is responsible for c5scoveflng available services which may come trani local or remote communication entitles, like devices or widgets. Services may become available or unavailable at any time,
First, the widget manager shall check the type of the widget interface and compare it with the string identifying the type of a service (e.g. the URN of the UPnP service). The exact comparison algorithm is service specific.
Then, if the types match, the widget manager shall compare the definition of the interface with the description of the service capabilities (e.g. UPnP actions and events) at the message level. For each message in the widget interface, there shall be a message in the service description with the same name. If this is not the case, the matching process fails.
Finally, for each message. the widget manager shall check:
— If. for each input in the widget message declaration, there is an output parameter in the service descnption, with the same name. If this fails, the widget manager shall check that there is a default value for this input. If this is not the case, the matching process fails. If after processing all input in the widget message declaration, some output parameters In the service description are not matched, the widget manager shall proceed with the assumption that these output parameters are not used in the widget.
– If for each output in the widget message declaration, there is an input parameter in the service description. with the same name. If this tale, the matching process tails.
In case of success of the matching process. the widget manager shall check that nodes or functions referenced m the widget interface declaration (see 10.23) are present in the widget representation when the matching process is performed. If this is not the case, the matching fails.
If the matching is successful, the interface is oorsideced bound and the widget manager shall notify it to the widget either using the rnw:indAction attribute (see 10.15)or using the onIntert,i.eBin callback in the API (see 9.2). In case of failure of the matching, the widget manager shall not bind the interface.