W3C home > Mailing lists > Public > www-forms@w3.org > August 2002

RE: Naming: select1 vs. singleSelect

From: Klotz, Leigh <Leigh.Klotz@pahv.xerox.com>
Date: Mon, 26 Aug 2002 14:55:32 -0700
Message-ID: <51B8ABCE456FD111899900805F6FD6EE0FF57995@mercury.ADOC.xerox.com>
To: "'Calbazana, Al'" <ACalbazana@epotec.com>, "'www-forms@w3.org'" <www-forms@w3.org>

Two points:
1. The minumum and maximum number of items that can selected comes from the
data model itself, not from the UI layer.
2. The two elements <select> and <select1> bind to different data types: a
simpleContent value for select, and a sequence of values (either
simpleContent or complexContent) for <select1>, and thus need different

Given that we needed two different names for the two elements, and we could
not use hyphenated names or camelCase and were discouraged from using
compound names, we considered having using other names for select and
select1; for example, "select" and "choose", but "choose" seemed to imply
that it worked with "choices" (see
http://www.w3.org/TR/xforms/index-all.html#ui-common-elements-choices), and
does not clearly indicate that only one choice is allowed.  The same problem
exists with "select" and "pick" (quick -- which one allowed only one
choice?)  Thus, we picked "select1" to clearly indicate that only one choice
is allowed, and chose "select" for the general case.


Details follow:

1. minOccurs/maxOccurs
The min/max number of items that can selected comes from the data model
itself, and from the UI layer.
It would be an abstraction violation to have the UI layer store constraints
about the data model; instead, the UI layer reflects the data model by
constraining the choices to the user based on the model definition.
The minimum and maximum number of values in a sequence are determined by the

  <xforms:bind nodeset="..." minOccurs="..." maxOccurs="... />
binding expressions, and are dynamically computed.  That is, the number can
change based on the current state of other values in the form.  

(How is it useful?  Aside from the general principles of UI and logic
separation, here is an example: you may be able to choose zero or one free
gifts on an e-commerce order page, but the maxOccurs can change to two free
gifts if your order total is greater than $50.00.  If this constraint were
on the <select> UI element, the model would not have a way to validate the
instance before submission if you were to select two free gifts and then
remove something else in order to get below $50, eliminating your
eligibility.  When such constraints are expressed at the data model layer,
the user agent can make sure the instance is valid at time of submission,
not just at time of interaction with a single UI control.)

When <select> binds to a node, it is responsible for constraining the number
of choices the user can make, based on the model.

Please see
for information on using XForms to control the number of allowed elements in
a sequence, dynamically.

2. The <select> and <select1> do different things and need different names:
* <select1> allows the user to make a single selection from multiple
It binds to one element with simple content and changes that content to be
the one value selected.
The value can be any string, including spaces.

* <select> allows the user to make multiple selections from a set of
When used with <choices> and <item> to specify values, select binds to any
simpleContent capable of holding a sequence (i.e., a space-separated list as
defined by XML 1.0) and populates it wih the values selected.  Because of
the restrictions in XML 1.0 on simpleContent sequences, the value cannot
contain spaces.
When used with <itemset> and <copy> to specify values, <select> binds to a
sequence and populates it with the sequence of values selected and the
sequence is not restricted to simpleContent (i.e., the selected value nodes
are copied into the sequence).

For information on select and itemset, see
The example in section 9.3.3. could be improved to show the use of
complexContent, rather than simply copying the text description and ignoring
the flavor single-character string that was used in the example in 8.1.11
for select1.

-----Original Message-----
From: Calbazana, Al [mailto:ACalbazana@epotec.com] 
Sent: Monday, August 26, 2002 12:21 PM
To: 'www-forms@w3.org'
Subject: RE: Naming: select1 vs. singleSelect

I agree with a previous post in that select1 implies a select2, select3,
etc...  Could it not be left as plain old "select" with an attribute
indicating the selectable elements in the set (1 or *)?


-----Original Message-----
From: Klotz, Leigh [mailto:Leigh.Klotz@pahv.xerox.com] 
Sent: Monday, August 26, 2002 1:57 PM
To: 'Piroumian Konstantin'; 'www-forms@w3.org'
Subject: RE: Naming: select1 vs. singleSelect


A strong goal of XForms integration with XHTML 2.0, and the XHTML Working
Group asked that we avoid hyphens and use only lowercase letters for element
and attribute names, which rules out both "selectOne" and "select-one".  

The all lower-case "selectone" is difficult to read in English, as it would
be pronounced "selec-tone", and is indeed used as such in at least one
trademark (http://www.com-spec.com/selectone/).

I don't think that trailing numerals in element names are unusual; see HTML
<h1>, <h2>, etc.

Thank you,
Leigh L. Klotz, Jr.

-----Original Message-----
From: Piroumian Konstantin [mailto:KPiroumian@protek.com] 
Sent: Monday, August 26, 2002 12:21 AM
To: 'www-forms@w3.org'
Subject: Naming: select1 vs. singleSelect


What is the reason of using a name like 'select1' for single choice
selection element?
Don't you think that this kind of name is absolutely unusual in XML, XSL,
XHTML or HTML worlds? What's wrong with 'selectOne' or
'singleSelect'/'multiSelect' names? Or maybe 'select-one' (using XSLT naming

  Konstantin Piroumian 
  Ivelin Ivanov
  Apache Cocoon: http://xml.apache.org/cocoon

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

Received on Monday, 26 August 2002 17:57:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:44 UTC