XForms to XHTML Stylesheet

rick frankel

cyberCode consulting inc

$Id: README.xml,v 1.1 2002/08/20 23:16:55 rick Exp $

Tue Aug 20 03:15:27 EDT 2002


Table of Contents

Contents
Sample Usage
Optional Parameters
Requirements
Overview
Support for the XForms Spec, section-by-section
2 Introduction to XForms
3 Document Structure
4 Processing Model
5 Datatypes
6 Constraints
7 XPath Expressions in XForms
8 Form Controls
9 XForms User Interface
10 XForms Actions

	  xsltproc --param list-size 3 xforms.xsl test.xml
	

There are 3 defaults (xsl:params) in the template which control the formatting of lists and textareas. The parameters and their defaults are:

The stylesheet has been tested with the xsltproc command-line processor.

The template requires an xslt processor which supports the following exst extensions:

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 of libXML is also backwards compatible w/ the saxon namespace.

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.

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.

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

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.