Projects‎ > ‎

XForms - For XML Documents

NOTE: This page describes an Orbeon Forms project, not a feature which is currently part of Orbeon Forms.


Currently in Orbeon Forms, XForms is used only within XHTML documents and produces XHTML documents out.

Another scenario that would make sense consists in using XForms within any XML documents. This allows using XForms instead of XPL/XSLT for producing XML output. The benefits of this are:
  • fewer languages to learn, just use XForms
  • xforms:submission is very powerful and missing entirely from XSLT
Use cases:
  • produce Atom or RSS feeds
  • produce XSL-FO documents
  • implementing REST services quickly


  • the result is an XML document without interactivity
  • no input controls are presented
  • only XForms models, AVTs, container controls and output controls really matter


Output options
  • "document" output:
    • similar to XHTML output: controls in the input XML document are handled
    • first option: just the plain text is output
    • second option: some additional metadata is added to allow identifying MIPs in particular
      • e.g. add/update @class on parent control (would not work for AVTs)
  • "instance" output: [DONE]
    • output one or more instances (in which cases controls are not used to produce the output)
    • NOTE: As of 2011-04-12, this is already possible with a submission[@replace = 'all'] upon initialization and the "echo:" URL scheme.
  1. use oxf:xforms-to-xhtml, oxf:xforms-to-xml, oxf:xforms-to-instance?
  2. use a single processor oxf:xforms
    • XHTML root element -> XHTML output (with maybe xxforms:processing="xhtml|xml|instance" options)
    • XML with xforms:version attribute -> XML
    • xxforms:output attribute on instance and/or xxforms:processing="instance" -> instance output
Ideally, it should be possible to provide an XForms document in the page flow and have the correct processing determined, so #2 seems good, even if #1 can also be implemented and reuse the same Java code.

Implementation steps:
  • XFormsAnnotatorContentHandler, XFormsExtractorContentHandler must not rely on XHTML
    • -> 2011-04-12: quick review shows there may not be really dependencies here
  • handlers
    • must not assume XHTML
    • or new hierarchies of handlers (which can be very simple) can be hooked up depending on the mode (XHTML, plain, plain with annotations)
    • must not be used, most likely, for the "instances" mode

Implementation notes

  • Added configuration entry oxf.epilogue.process-xslfo (type xs:boolean) which defaults to true. When you want to output annotated XSL-FO + XForms you should set this property to false, otherwise the XSL-FO is converted to pdf using fop