3.4 Selecting from a Set of Values

Next to free-form input, user selection based on a set of constraints is perhaps one of the most common facilities provided by user interfaces today. Such selection often manifests itself in a visual interface in the form of pull-down lists or radio buttons . When using smaller sized devices, for example, digital cameras or cell phones, such selections show up as nested menus that progressively guide the user to a specific selection.

XForms defines selection controls based on the functionality provided, rather than their appearance in a given environment. This design has the advantage of capturing the underlying intent in a given user interaction rather than its mere visual appearance. Thus, consider a selection control that allows one to specify one's gender by picking from a pair of mutually exclusive values. Rendering such a control as a group of radio buttons may be appropriate for a visual interface; however, designing the user interface markup based on this choice of presentation leads to content that fails to capture sufficient information. For instance, the HTML markup shown in Figure 3.8 does not explicitly capture the underlying intent of the user interaction being authored . An ideal auditory representation of the user interface created by Figure 3.8 might be to produce a spoken prompt of the form

Figure 3.8 HTML radio buttons fail to capture the intent underlying the user interface.

 <  fieldset  > <  input   id  ="g1"  type  ="radio"  checked  ="checked"  value  ="m"  name  ="gender"/> <  label   for  ="g1">Male</  label  > <  input   id  ="g2"  type  ="radio"  value  ="f"  name  ="gender"/> <  label   for  ="g2">Female</  label  ></  fieldset  > 

Please specify your gender ; default is male .

As a consequence of the HTML markup in Figure 3.8 failing to capture explicitly the relationship among the radio buttons, providing the desired nonvisual presentation of this control becomes difficult. Capturing the appearance of a user interface, rather than its underlying intent, can make it significantly harder to retarget an application to different modalities and devices.

Notice further that the markup in Figure 3.8 uses HTML construct label to associate each control with its label. This association is made by creating a unique id for each control and specifying this id as the value of attribute for on the label elements. This construct was added in HTML4 for enabling the design of accessible Web interfaces; however, the level of indirection present in this design has caused it to be rarely if ever used on today's mainstream Web.

Contrast this with the XForms version of the same user interface shown in Figure 3.9; here, the interface is accessible by design since the user interface labels are a mandatory part of the markup making up the control. Notice further that when working with the HTML markup shown in Figure 3.8, the relationship among the radio buttons needs to be inferred from the fact that both controls have an identical value of gender for attribute name . The XForms markup makes this fact explicit by encapsulating the available choices as child elements of control select1 .

Figure 3.9 XForms user interface markup for picking from a pair of mutually exclusive values.

 <  select1   xmlns  ="http://www.w3.org/2002/xforms"  ref  ="/person/gender"><  label  >Gender</  label  > <  item  ><  label  >Male</  label  > <  value  >m</  value  ></  item  > <  item  ><  label  >Female</  label  > <  value  >f</  value  ></  item  > </  select1  > 

Finally, notice that there is no means of explicitly associating a label for the group of radio buttons in the HTML markup. The XForms version of the same control can encapsulate label Gender as an immediate child of element select1 . In addition, common elements help and hint , described in Section 3.2.3, can be used to attach tooltips and help to each of the choices; similar functionality would require using browser-specific scripting in the case of traditional HTML forms.

3.4.1 Types of Selection Controls

Presentation and interaction behavior aside, selection controls can be characterized by the atomic or list nature of the data they collect. XForms defines selection control select1 for creating selection controls that return an atomic value; control select creates selection controls that return a list of values. ^[6] Notice that this design creates separate selection controls based on the underlying functionality, rather than the appearance of these controls in any given interface, for example, pull-down lists or radio buttons.

^[6] Note that the working group agonized long and hard over these names, and we went through a sequence of name choices. The final choice was agreed on because it was both succinct and did not require the use of mixed case in the element names .

Consider the selection control used in a questionnaire that allows the respondent to specify one of two gender values, M or F . These values are mutually exclusive, that is, the user can pick one and only one of the available values. A typical visual interface might render this control as a group of two radio buttons, and the result of user interaction with such a user interface control is an atomic value.

Contrast this with a U.S. tax form that lets users specify the states in which they worked during a given calendar year. Users can pick one or more values from the 50 states; here the selections are not mutually exclusive. This control might be rendered by a typical visual interface as a pull-down list, and the result of user interaction with this control is a list of one or more states.

Controls select and select1 share a common set of attributes and child elements in addition to the ones described in Section 3.2. These selection- related attributes and child elements will be described in the rest of this section along with examples that illustrate their use.

3.4.2 Open and Closed Selections

Selections such as picking a state from a list of available states require the user to pick from the set of choices; such controls are called closed selections. Contrast this with a user interface where the user can pick from a set of predetermined choices, or alternatively specify a conceptual other value, that is, a value that does not appear in the set of predefined values. Such controls are called open selections. XForms selections controls select and select1 are closed by default; a selection control can be declared open by setting attribute selection to open . See Figure 3.10 for an example. Visual user agents might render such an open selection by juxtaposing a text entry field next to the selection control (see Figure 3.11).

Figure 3.10 Open selections permit selecting from a set as well as free-form input.

 <  select   xmlns  ="http://www.w3.org/2002/xforms"  ref  ="/pizza/topping"  selection  ="open"> <  label  >Toppings</  label  > <  item  ><  label  >Mushrooms</  label  > <  value  >mushrooms</  value  ></  item  > ...</  select  > 

Figure 3.11. Open selections permit selecting from a set as well as free-form input.

3.4.3 Default Selection

Selection controls often come with one or more default choices already selected when appropriate. In the HTML example shown in Figure 3.8, this is achieved by setting attribute checked to the value checked . Notice that the equivalent XForms example shown in Figure 3.9 does not have any of the choices checked . The question therefore arises as to how one specifies default choices when using XForms.

The missing checked attribute in the XForms version of the selection controls is a consequence of the separation of the model from the interaction present in the XForms design. The values selected via the selection controls select and select1 are stored in the XForms model and not within the user interface control. Consequently, it is more natural to set default values in the model. Notice that doing so treats default values in the same way as values picked by the user. Figure 3.12 shows the corresponding model for the gender picker shown in Figure 3.9 with a preassigned value of m . When the user interface control shown in Figure 3.9 binds to this model, the choice corresponding to m becomes selected.

Figure 3.12 XForms model fragment for gender picker.

 <  model   xmlns  ="http://www.w3.org/2002/xforms"  id  ="p1"> <  instance  > <  person   xmlns  ="">... <  gender  >m</  gender  >... </  person  ></  instance  > </  model  > 

The design shown earlier has numerous advantages over the traditional HTML design of specifying default values within the user interface markup.

Auto Fill

It is now significantly easier to fill a form automatically with a set of values. Doing this in the case of HTML requires locating every user interface control that collects a particular value and then setting the default values of that control by manipulating its markup. Contrast this with the XForms design that permits one to load data from an XML document into the form.

Defaults

Storing default values in the model ensures that such defaults are valid for a given application. In contrast, specifying default values within the user interface controls would mean that an incorrectly authored form might potentially contain incorrect defaults. This can lead to a bad end-user experience when a user does not change an erroneous default and later gets an error for something the user was not responsible for.

3.4.4 Selections Using Static Choices

The previous section described how the XForms model is used to provide default values for user interface controls, including the various selection controls. Viewed from the viewpoint of separating the model from the interaction, the selection controls as shown so far do not go all the way with respect to this separation. Notice also that in the examples shown so far, the available choices, including the values that get stored in the model, appear in the user interface markup.

This design pattern was adopted intentionally to smooth the transition from traditional HTML forms to XForms. One consequence of authoring the available choices within the user interface controls is that the choices become static , that is, the available choices need to be determined at the time the XML markup is authored. However, this design works well only in cases where the available choices are known at authoring time. The next section describes XForms constructs that allow the author to move the available choices from the user interface markup to the XForms model. This introduces a level of indirection that enables the creation of dynamic selections. Lacking this facility, today's HTML authors resort to browser-specific scripting in order to update dynamically the list of available choices as the user interacts with an application.

3.4.5 Dynamic Selections

Dynamic selections in XForms are enabled by having selection controls refer to a portion of the XForms model that contains the choices rather than enumerating these choices directly within the user interface markup. Element itemset can be used as a child element of selection controls select and select1 to specify the location that holds the choices. The location is specified using the standard XForms binding mechanism based on XPath described so far. As the name implies, element itemset points at the set of available choices.

Referring to such sets comes naturally to XPath, which has been designed to work with sets of nodes. In fact, XPath locators always evaluate to node-sets . In the examples shown so far in this book, we have used XForms binding expressions that needed to select a single node; we consequently specified such expressions using attribute ref . When attribute ref is used, XForms processors use the first element of the resulting node-set. Binding expressions that wish to operate on an entire node-set use binding attribute nodeset instead of attribute ref . To summarize,

Single Node	Use attribute pair ( model , ref ) to specify the location when binding to a single node. The result is to operate on the first node in the node-set addressed by the XPath expression specified as the value of attribute ref from model model .
Multiple Nodes	Use the attribute pair ( model , nodeset ) to specify the location when binding to set of nodes. The result is to operate on all of the nodes in the node-set addressed by the XPath expression specified as the value of attribute nodeset from model model .

To return to the topic of dynamic selections, element itemset is used to specify the location in the model that holds the available alternatives. Child elements value and label of element itemset refer to a prototype member of this set. The XForms processor expands element itemset at run-time to produce the list of choices by instantiating child elements label and value once for each element in the node-set just selected. Child elements label and value in turn can refer to portions of an individual element in the set by using XPath locators. Thus, in the case of an electronic book store, the available alternatives may be extracted from an online catalog. Such an online catalog might hold each book as an XML structure, with appropriate attributes and child elements. When creating a dynamic selection that operates over such a catalog, how the constructs described so far would be used are shown in the following figures: Figure 3.13 and Figure 3.14 for the XML markup and Figure 3.15 the corresponding visual interface.

Figure 3.13 Book catalog used to provide available choices.

 <  head   xmlns:xf  ="http://www.w3.org/2002/xforms"> <  xf:model   id  =" bookshelf "> <  xf:instance   xmlns  =""> <  shelf  ><  books-picked  /></  shelf  > </  xf:instance  > </  xf:model  > <  xf:model   id  ="catalog"> <  xf:instance   xmlns  =""> <  catalog  > <  book   isbn  ="0-2014-8541-9"> <  title  >Art of Computer Programming</  title  > <  author  >Donald E. Knuth</  author  > </  book  > <  book   isbn  ="0-7923-9984-6"> <  title  >Auditory User Interfaces</  title  > <  author  >T. V. Raman</  author  > </  book  >... </  catalog  ></  xf:instance  > </  xf:model  ></  head  > 

Figure 3.14 Available choices can be updated dynamically.

 <  select   xmlns  ="http://www.w3.org/2002/xforms"  model  ="bookshelf"  ref  ="/shelf/books-picked"> <  label  >Select books</  label  > <  itemset   model  ="catalog"  nodeset  ="/catalog/book"> <  label   ref  ="title"/><  value   ref  ="@isbn"/> </  itemset  ></  select  > 

Figure 3.15. Visual presentation of the bookstore user interface.

Model	Create a model that holds an appropriately filtered instance of the book catalog. The contained instance might appear inline or be addressed via a URI .
UI Select	Create a selection control that stores selected values in the bookshelf instance. For this example, we assume that the ISBN of each selected book is stored in the bookshelf.
Alternatives	Create an itemset child element of the selection control that locates the set of available alternatives via an appropriate binding expression.
Label	Within element itemset , create element label that specifies the label to display for a given choice. For this example, we will display the title of the book. The title is retrieved by addressing subelement title of element book .
Value	Create child element value of element itemset to specify the value to be stored as the result of selecting a given book. We have decided to store the ISBN in the bookshelf, and it is found as the value of attribute isbn in each book element. We therefore create the appropriate binding attributes for element value that extracts attribute isbn from book .

In the case of this example, an XForms processor can dynamically update the available books during user interaction. This is because the choices are not statically authored within the user interface control; instead, like the XForms user interface controls, the choices too are bound to the model. Thus, dynamically updating the available choices in the model results in the user interface being refreshed to display the newly available choices.

3.4.6 Selecting XML Structures

In the examples shown so far, selection controls have been used to pick atomic data types from a set of choices. When viewing XForms as the means to edit and manipulate XML structures interactively from within a Web browser, it is often useful to select entire XML subtrees as opposed to just selecting atomic data types such as strings and numbers .

As an example, we stored the isbn of the book being selected in the example shown in Figure 3.14. Consider an example where the entire book structure is to be stored in the bookshelf model. In this case, the storage value is not a string value as was the case when storing the isbn ; instead, here we are copying the entire book structure to the bookshelf model. XForms enables this via element copy , which can be used in place of element value .

Element copy encodes the information about what nodes are to be copied via standard XForms binding expression ”see Figure 3.16 and Figure 3.17.

Figure 3.16 Bookshelf stores complete book structure.

 <  head   xmlns:xf  ="http://www.w3.org/2002/xforms"> <  xf:model   id  ="bookshelf1"> <  xf:instance   xmlns  =""> <  shelf  > <  books-picked  /> <  book  >...</  book  > </  shelf  > </  xf:instance  > </  xf:model  > <  xf:model   id  ="catalog"> <  xf:instance   xmlns  =""> <  catalog  > <  book   isbn  ="0-7923-9984-6"> <  title  >Auditory User Interfaces</  title  > <  author  >T. V. Raman</  author  > </  book  >... </  catalog  > </  xf:instance  > </  xf:model  ></  head  > 

Figure 3.17 Element copy used to select XML structures.

 <  select   xmlns  ="http://www.w3.org/2002/xforms"  model  ="bookshelf1"  ref  ="/shelf/books-picked"> <  label  >Select books</  label  > <  itemset   model  ="catalog"  nodeset  ="/catalog/book"> <  label   ref  ="title"/><  copy   ref  ="."/> </  itemset  ></  select  > 

The shelf model has been updated to hold one or more book elements and is given an id of bookshelf1 . The user interface has been modified to use element copy instead of element value . The binding expression on element copy

 ref="." 

specifies that selecting a given item results in the current node being copied to the storage location specified by the containing select control.

The current node is determined by the current evaluation context; in this case, this context is set by the containing itemset . As before, element itemset iterates over the books in the catalog. When processed , this example produces the same user interface as when using element value to store the isbn into the bookshelf ; however, the XML instance that is produced by these two user interfaces is different.

The example shown in Figure 3.14 results in a bookshelf structure that contains a set of string values; in contrast, the example in Figure 3.17 produces a bookshelf structure that contains one or more book children.

Thus, when providing dynamic selections via element itemset , the XForms author has two options:

value	Use element value if the value to be stored is an atomic data type, for example, a string or number .
copy	Use element copy if the value to be stored is an XML structure, for example, the subtree corresponding to a given book.

3.4.7 Grouping Available Choices

Navigating through large lists of choices can become cumbersome when using small-sized displays or nonvisual modalities such as speech. Imposing additional structure on the available choices can help in presenting a more usable interface in such cases. Element choices provides functionality similar to that provided by HTML optgroup ; however it has better support for attaching labels to each group of choices. We demonstrate this with an example in Figure 3.18 along with the corresponding visual presentation in Figure 3.19.

Figure 3.18 Grouping available choices.

 <  select   xmlns  ="http://www.w3.org/2002/xforms"  ref  ="/pizza/topping"  selection  ="open"> <  label  >Toppings</  label  > <  choices  ><  label  >Vegetarian</  label  > <  item  ><  label  >Mushrooms</  label  > <  value  >mushrooms</  value  ></  item  > <  item  ><  label  >Tomatoes</  label  > <  value  >tomatoes</  value  ></  item  > </  choices  > <  choices  ><  label  >Meat</  label  > <  item  ><  label  >Pepperoni</  label  > <  value  >pepperoni</  value  ></  item  > <  item  ><  label  >Salami</  label  > <  value  >salami</  value  ></  item  > </  choices  > </  select  > 

Figure 3.19. Visual presentation of a hierarchical selection control.

3.4.8 Rendering Selection Controls

Attribute appearance can be used to influence the concrete representation used for a selection control. XForms 1.0 recommends the interpretation that follows for the predefined values of attribute appearance when used with selection controls.

minimal	Requests a presentation that takes a minimal amount of display real estate. A visual browser might choose to render selection controls having appearance=minimal as a pop-up list.
compact	Requests a presentation that displays some of the available choices with facilities for navigating through the remaining choices. Visual browsers render such controls as scrolling lists.
full	Requests that all of the available choices be displayed if possible. Visual interfaces use radio buttons in the case of select1 and checkboxes for select .