XForms 1.2 Design Principles, Forms Architecture

To feed the Forms Joint Task Force discussion on "Architecture of Forms", 
I think it makes sense to succinctly state the principles that are guiding 
the design of the XForms 1.2 syntax.  This is only my take on it, and I 
hope this can be honed and refined through group discussion this week and 
early next week so we can send something like this out to the task force 
later next week.


1) The same forms vocabulary must be expressible in XML syntax and a 
non-XML web syntax.


2) The forms vocabulary must leverage terms from W3C Recommendations where 
it is possible to do so in lieu of new terms.  Simple extensions to 
existing terms must take priority over new terms.


3) The forms vocabulary must allow a seamless mapping from a conceptual 
single-layer authoring style to the model-view-controller-submission 
architecture of XForms.

This is the fundamental goal of the task force communicated in the WG 
charters as well as being another way of saying principles #1 and #2.


4) The forms vocabulary must allow the use of terms familiar to today's 
web authors for the conceptual single-layer authoring style. 

This is a facet of principle #2 as applied to the HTML Recommendation.


5) The forms vocabulary must allow the terms that map to the XForms 
architecture to be extended to terms that are unique to the HTML forms 
presentational layer.

For example, a named div in HTML corresponds to a named group in XForms 
vocabulary.  This is necessary because of the precedence of div in the W3C 
HTML Recommendation (principle #1).  However, this is not intended to 
allow new feature creation with terms that ignore obvious existing terms 
in other recommendations like XForms (principle #2).


6) The forms vocabulary must allow incremental author opt-in of the key 
components and processing models of XForms as they are needed.

This is a facet of principle #2 as applied to XForms.

6a) instance for declaring a block of XML.
6b) submission once server communication of XML data is needed during form 
execution
6c) bind for declaring calculations of data values and properties on 
declared blocks of XML
6d) Single node binding attributes (e.g. ref) for attaching form controls 
to declared XML data
6e) Access to setvalue, insert and delete as actions and as DOM script 
functions as data manipulation needs arise
6f) group as form control aggregation needs arise
6g) repeat and setindex as row-based content duplication needs arise
6h) switch and toggle as conditional content needs arise
6i) output as display needs arise for calculated results or declared XML 
data
6j) other controls such as select1, trigger, submit as the needs for their 
semantics arise


7) The forms vocabulary must allow a named form control to be synonymous 
with the datum it collects, thereby implying a data layer.

This is an aspect of principle #3.

7a) In order to imply a data layer, there must be a containment element to 
define the collection of controls included in the data layer.  Due to 
principle #2 and #4, this must be the form tag.
7b) A means of naming the form controls is needed.  Due to principle #2 as 
applied to HTML, this needs to be the 'name' attribute.


8) The forms vocabulary must allow the data layer to be hierarchic based 
on hierarchy expressed in the user interface.

8a) It must be possible to express simple hierarchy with a named group 
element.
8b) It must be possible to express conditional hierarchic content with a 
named switch element.
8c) It must be possible to express repeated hierarchic content with a 
named repeat element.
8d) It must be possible for data hierarchy to be implied by the name 
attribute so that HTML to use other grouping elements like div.


9) The forms vocabulary must allow simple declarative XPath expressions 
for dynamic data value and property calculations. 

9a) The expressions must be able to access the data layer using a simple 
XPath variable syntax that maintains the flat model conceptualization 
familiar to web authors
9b) The expressions must be able to access the data layer using simple 
XPath location paths that follow the structure of the user interface.  An 
expression in a form control attribute must be able to access the value of 
a sibling form control with a location path containing zero slashes.
9c) Aside from the XForms precedence of using XPath for these expressions 
(principle #2), XPath is used in lieu of javascript because it avoids 
conflicts arising from ability to mutate the DOM with javascript 
functions, which conflicts with the intent of the declarative calculation 
system. 


10) The forms vocabulary must allow properties of a datum to be expressed 
as attributes of the corresponding form control in the conceptual 
single-layer authoring style.

10a) An attribute called "calculate" must be used to express an XPath for 
the value of the datum (and hence the form control).
10b) An attribute called "relevant" must be used to express an XPath for 
whether the data and form control are suitable for rendition and 
submission
10c) An attribute called "readonly" must be used to express an XPath for 
whether the data is modifiable.  For compatibility, the special keywords 
'readonly' and 'true' must be recognized before interpreting the attribute 
content as an XPath
10d) An attribute called "datatype" must be used to associate an XForms or 
XML schema datatype with the data of the form control.  This attribute is 
mapped to the "type" attribute from XForms, but the name "datatype" is 
used due to the use of preceding use of "type" in HTML form controls.


11) The forms vocabulary must allow dynamic change to the presentation via 
mutation of the data layer.

11a) The data manipulation actions of XForms (insert, delete, setvalue) 
must be exposed to Javascript with sensible parameter defaults that keep 
authoring simple and based on the names established by the name attribute 
on form controls.
11b) It must also be possible to express mutations as declarative form 
control event handlers.
11c) It must be possible to express dynamic interactive web applications 
without explicit use of javascript.


12) The forms vocabulary terms must work in HTML with no namespace 
qualification.

12a) Attributes derived from XML events must be imported, especially 
event, target and phase.
12b) Elements and attributes from XForms must be imported.
12c) The null namespace must automatically used for the implied data layer
12d) The instance element from XForms needs work to ensure that 
unqualified data content is regarded as being in the empty namespace.

Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw