Greetings,

 

These comments are for the V2 committee, for the INCITS 389 standard, submitted during the public review period:

 

Comment #1:

The view of the Target seems too narrow in Section 5.1, p. 9 near bottom.  In most implementations the Socket will reflect only a subset of the states within the Target; indeed, when the Target is a Service this might be a very small subset. Targets can be sophisticated, with many internal states, yet have simpler interface sockets.

 

The following is a suggested change in text within Section 5.1 (p. 9);

Each Target provides a User Interface Socket (or short "Socket")[GZ1] , or set of Sockets, through which a URC can access part or all of the Target's internal states and provide control inputs to it. 

 

Comment #2:

Figure 1 (p 12) includes the phrases “Java/Jini ON” and “UPnP ON” – these are not part of the standard, but rather are suggestive of possible implementation frameworks, and as such can be misleading.  It seems better for the figure to reflect pure V2. It is suggested that they be removed from this figure.  If desired by the committee, perhaps they could be given as examples in the legend for Figure 1.

 

Comment #3:

Consider the case where the size of the Target’s socket is relatively large, and the Target sophisticated.  The URC interface generator has a challenging task. This comment relates to a concern regarding the lack of direct mechanisms within V2 for enabling a Target to share evolving “intelligence” and “context awareness” with the URC interface generator.  Context-awareness can relate to the (perhaps changing) abilities/preferences of the user, environmental information, the state of the socket elements, user task performance during a protocol, Target application requirements, etc.  For certain control sessions, it may be the Target that is best equipped to provide certain types of context-awareness – indeed, it is likely that the URC has access to only a small fraction of the internal states and structure within the Target.  These states may change over time, and as a consequence the optimal information to be “present” to the user (PRE-sent, not pre-SENT) may change.  Such a change relates to the degree of presence (“what to have reasonably present”) rather than interface presentation (“how to present”).  The PreT protocol addresses the latter, but really could only address the former only if the “hints” provided through “groups,” etc., could evolve as a function of state.  Socket elements within a group could have different degrees of “presence,” which could be especially important when the URC is a mobile device having to order degrees of access.  “Presence” is a developed concept, e.g. there is a “Presence” journal (by MIT Press). So how does the Target share this, given that most V2 documents are static or minimally dynamic? It is proposed that the values and attributes of Resource documents be allowed to be dynamic without a name change, and that the “Notify” element of the Socket be expanded to allow notifications that are intended for the URC interface generator as well as the currently designated notifications intended for the user.  For the URC document (INCITS 389), the following are possible changes in text in three locations that might help implement this comment, if it is deemed useful:

 

Section 6.2.3, p. 14:

Document retrieval may happen in both the discovery and control phase.  During the control phase, the notify element of the socket may be used by the Target to inform the URC of changes in a Target Resource, for instance new suggestions (e.g., for presentation, of relative importance of groups within a Presentation Template) to the URC.

 

Section 6.7, p 20:

As a consequence, when the URC has multiple Resources available to fill a single role in the user interface construction, such as multiple labels that all are applicable to the same interactor, in the absence of user preferences indicating otherwise the Resources provided by the target and target vendor should be used in preference to those offered by third parties. Additionally, more complex Targets such as services may provide updated suggestions for interface generation by dynamically changing values (but not structure) within a Target Resource during a control session.  The URC is informed of such changes through use of the notify element in which the Information or Alert attribute is directed to the URC rather than the user. For instance, a Target supporting a large socket and services might change a Target Resource based on its ongoing evaluation of user performance or changes in internal states.  Based on this advanced context-awareness capability that is only possible because of the Target’s knowledge of its application, it could then change the suggestions within a Resource and then notify the URC that the suggested degree of presence prioritisation has changed for certain types of information.   

 

Section 7.2.2, p. 22:

Notifications are triggered by the Target.  Notifications are special states where in many cases normal operation is suspended to alert the user or request user action, such as an exception state.  Notifications may also be used to alert the URC of a dynamic change in a Resource document during a control session.   

 

 

All of these suggestions, plus a few typos, are provided in the attached edits of the INCITS 389 Document.

 

If the V2 committee favors Comment #3 on expanding Resource-Notify in some flavor that enables to Target to help assist the Interface Generator, there would also be small changes to the Resource and Socket standards documents.

 

Thank you for your consideration,

Jack

 

 

________________________________________________

Jack Winters, Ph.D.                                     414-288-6640 (wk)

Prof. of Biomedical Engineering             414-288-7938 (fax) 

& John P. Raynor Distinguished Chair           PO Box 1881

Dept Biomedical Engineering           Milwaukee WI 53201

Marquette University                           jack.winters@mu.edu

& Adjunct Prof, PM&R, MCW