
NOTE: This documentation is out of date and will be replaced in the next
      release!

Xforms to (x)html conversion templates

* Contents

	xforms.xsl	xforms->html template
	xforms.css	Css stylesheet for the above
	test.xml	Test input

* Sample Usage

		xsltproc xforms.xsl test.xml

The template attempts to handle as much of the Xforms RFC as possible
w/o client side procesing or multi-pass transformations. Obviously,
w/o client side processing things such as  events, actions, control flow and
interleaved model specific controls cannot be handled.

Three extension functions are used:

	str:tokenize	for handling multi-valued select instance data
	dyn:evaluate	for instance data
	func:function 	for accessing model nodes and more.

Note that the dyn prefix is mapped to the http://icl.com/saxon
namespace, which is available in the current release version of
libXML. When the cvs version is released, the evaluate function will
also be mapped into the http://exslt.org/dynamic namespace and the
template can be changed. However, it seems that at least for the
moment, the cvs version is also backwards compatible w/ the saxon
namespace.

This version operates in xslt push mode. Any text or nodes
(w/attributes) not in the xforms namespace are copied to the output as
is. It handles multiple forms, but assumes that ALL the controls for
each form are wrapped in an outermost xforms:group, in the same sense
as binding elements are considered outermost in in section 7.3 of the
xforms spec (that is, the xpath expression ancestor::xforms:group
returns the null set).

It also assumes that the input contains all non xforms  tags (e.g., html,
head, body) required to generate a valid output document.

Note that <xforms:select* selectUI='listbox"> default to a size of 5
lines. This can be overridden w/ the input parameter
'list-size'. e.g.,
			 
			 xsltproc --param list-size 6 ...

The xforms:textarea outputs rows and cols attributes in the html textarea
(required for HTML 4.0.1 strict compliance). These are defined as the
stylesheet parameters textarea-row (default  5) and textarea-cols
(default 20); both arbitrary numbers.

selectMany bindings are handled (I think) per the spec. That is, the
instance data is assumed to be a space separated list of data, as in:

		 <mult-input>1 2 3</multi-input>

Currently, nodeset attributes are assumed to be relative to
xforms:instance (the root of the pseudo document as defined in the
spec), as I cannot deduce from the spec whether they inherit outer
context. If you want to bind a itemset to a relative reference, you
can use a bind attribute. The bind element will be parsed as a
relative path.

An xforms::group with the class attribute 'no-display' can be used for
context grouping and will not generate a 'div' element in the
output. This is useful for generating instance context per section 7.3
of the spec without breaking e.g, a css table model. The template
also ignores any caption, hint or common-attributes (class, accessKey)
associated with the group.

Name attributes on the html form elements are generated according to
the spec. That is, if the encoding is "application/x-www-urlencoded",
the name will be the local-name() of the data node. Any other
encoding (default multipart-form-data) will be the xpath to the data.

*  What's not handled

   - xforms:range
   - xforms:group for checkbox and radio lists
   - assigning to instance data
   - events
   - xforms control flow statements (switch, etc)
   - xlink expressions
   - xforms:alert

** Section by section

   - 3.7 Privacy
   - 3.8 XForms and XLink
   - 4 Processing Model
   - 5 Datatypes (don't process schemas)
   - 6 Constraints (note that bind ref is processed appropriately)
   - 9.2 switch
   - 9.3 repeat
   - 10 XForms Actions


Feedback appreciated, of course.

Usual disclaimers apply (no warranty, use at your own risk, may
destroy your hard disk ...)

Enjoy,

rick frankel
rick@rickster.com
