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

Form function and presentation

From: Michael Ramirez <MichaelR@Aptimus.com>
Date: Tue, 7 Aug 2001 10:17:46 -0700
Message-ID: <8498F575269ED411A57300D0B790A51202D57D58@MERCURY>
To: www-forms@w3.org
Hello --
I've been working with forms and XML for some time now with www.aptimus.com
and came across the working draft of XForms.  I've run into a few problem
areas and it looks like XForms is addressing these issues.  I wanted to find
out if this is true and how these issues are being addressed.

The basic structure of the part of the DTD I've been using has been this:

<!ELEMENT QUESTION_LIST (FIELD+)>
<!ELEMENT FIELD (OPTION*)>
<!ATTLIST FIELD
	LABEL CDATA #REQUIRED
	FIELDORDER CDATA #IMPLIED
	REQUIRED CDATA #REQUIRED
	PARAMETERNAME CDATA #REQUIRED
	PARAMETERVALUE CDATA #IMPLIED
	SIZE CDATA #IMPLIED
	MAXLENGTH CDATA #IMPLIED
	TYPE CDATA #REQUIRED	
>
<!ELEMENT OPTION (#PCDATA)>
<!ATTLIST OPTION
	SELECTED CDATA #REQUIRED
	LABEL CDATA #IMPLIED
	PARAMETERVALUE CDATA #IMPLIED
	TYPE CDATA #REQUIRED
	OPTIONORDER CDATA #IMPLIED
>

You'll notice I haven't separated out some of the "presentation" from the
data.  The "presentation" info is just another piece of data being
dynamically populated in the XML tree using Java code, and though the "how"
of the presentation is for the most part taken care of by the XSL
Transformations, there are some details that can't be left out of the XML.

Now, the issues I've run into all have to do with grouping in some form or
another, whether it be for display purposes or validation:

*	Validation -- for the most part, by this I mean front end validation
using a client-side script.  Consider form fields for credit card info.  Two
fields might be credit card TYPE and credit card NUMBER.  The NUMBER may be
correct by itself, but not if the TYPE is invalid, or vice versa.  I'm
envisioning a method where the XML would be able to indicated to the XSL
what kind of validation script is needed.  A more complicated scenario might
arise as well, where any number of fields might be interconnected in the
validation process, each relying on the other.  In some way, those form
fields need to "know" about each other in the XML so that when the page is
transformed, the script can handle the validation.
*	Display -- in a simple case scenario where the display of form
fields is always the same, the display and grouping of form fields might not
be an issue.  In my case, I need the form field presentation to be entirely
dynamic, based on criteria from clients or users, and it seemed the best way
to handle this would be to populate the XML with "presentation" data.  I
have some ideas about how to handle this, but I'm still looking for
suggestions.  A simple example would be a group of checkboxes.  Should they
be displayed horizontally or vertically, how many checkboxes should be
displayed in each column or row, etc.  To make this a more dramatic example,
imagine there are three groups of checkboxes which all fall into a larger
group.  For instance, there might be a question like: What kind of magazines
do you like?  Then, there might be three groups of checkboxes, one for
Sports-related magazines, one for Literature-related magazines, and one for
Gardening.  Then the problem compounds itself because not only would we need
to know how to display the groups individually, but also as part of a whole.

So, I was wondering if these are some types of issues XForms aims to solve,
and if so, how?  If there are other standards I need to look at, would
someone direct me in the right place?  Any other suggestions would be
welcome as well!

Much thanks,

Michael Ramirez


Michael Ramirez
Software Engineer 
Aptimus, Inc. 
Ph. (206) 441-9100 ext. 252
Received on Thursday, 9 August 2001 07:10:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:49 GMT