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

RE: Form function and presentation

From: Josef Dietl <josef@mozquito.com>
Date: Tue, 14 Aug 2001 17:38:01 +0200
Message-ID: <D0F1529EE943B3449F755CA1A408874652632D@winserver.windomain.mozquito.com>
To: "Michael Ramirez" <MichaelR@Aptimus.com>, <www-forms@w3.org>
Hello Michael,

first of all, my apologies for the slow response, it is vacation time
all over XForms-land.

You appear to have fairly ambitious goals with your forms handling. As
XForms is developed in a W3C contect, it is probably more useful to move
to the bigger W3C framework in order to answer your questions:

First, XForms is completely based on XML Schema. Schema is the future,
and the more we dive into developing XForms, the more we realize that it
would have been impossible to build based on DTDs. Besides, DTDs just
don't offer the content validation features that we want. 

That said, even Schemas don't provide validation to the extent you
propose. So we have introduced an additional constraint, an attribute
called validate that is attached to the data item. The value of that
attribute is a predicate that needs to be satisfied for the associated
instance data item to be considered valid. That would be a place where
you can express "date of birth < date of death". Anything that you can
stuff into an XPath expression that evaluates to a boolean, roughly. So:
probably not sufficiently sophisticated for your credit card example,
but fairly close. For the complex cases, you will still need a small bit
of script.

With respect to rendering, XForms is really extremely flexible. This is
because XForms isn't built as a stand-alone language but as a vocabulary
for inclusion in other languages. Obviously, we are working on
integration with XHTML to start with, but we are also looking for
example at SVG or VoiceXML. I could now try to duck the question by
saying: XForms will do whatever the host language does (in fact that is
true anyway :-). For the XHTML case, a combination between CSS and XHTML
should be able to do the trick - though the details are not hammered out
yet.

Either way: your questions are very valuable. Please go on.

Hope this helps,

Josef

> -----Original Message-----
> From: Michael Ramirez [mailto:MichaelR@Aptimus.com]
> Sent: Tuesday, August 07, 2001 7:18 PM
> To: www-forms@w3.org
> Subject: Form function and presentation
> 
> 
> 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 Tuesday, 14 August 2001 11:38:34 GMT

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