Wednesday, May 15, 2013

Automatic schema generation for forms you create in Form Builder

When you create a form with Form Builder, behind the scene, data entered by users in the form is collected in an XML document. That same XML document is sent to the persistence API, and if you are using one of the built-in implementations of the persistence API, that XML document is also saved in your database of choice.

The structure of those XML documents is driven by the names you give to sections, repeats, and controls when you create your form in Form Builder, so you know what the XML will look like. But what if downstream, software is consuming those XML documents? A better way to communicate what the XML "looks like" to software is by using an XML schema. And this is why Orbeon Forms 4.0 PE introduced a new service which can automatically produce an XML schema describing the structure of the XML data collected by each form you built with Form Builder.

The service that produces the schema is accessible at /fr/[app]/[form]/schema for versions 4.0 to 4.3 and at /fr/service/[app]/[form]/schema for versions 4.4 and newer. Like other services, since 4.0, it is protected by default, and thus isn't just accessible by end users trying to load that URL.


  1. Is there a "no easy way" for CE?

  2. Wagner, I am not sure I understand your comment. Can you please clarify?

  3. Cool, have you also thought about kinda the reverse: data structure -> orbeon form.

    I mean having a schema that validates the xforms dialect which is understood by the form builder. This would allow to automatically generate an Orbeon form from existing data structures e.g. by XSLT, programmatically, by hand etc. The advantage to just writing/generating these forms in vanilla xforms would be that the user could load them into form builder and tweak them...

    Extending this day dream: It would be great to define rules to what extend teaking was allowed e.g. just changing the font size vs using an alternative widget (which still results in the same data) vs changes that would change the produced data

    To understand where this day dreaming comes from: I am involved with the openEHR project ( that aims at improving patient record interoperability by defining computable, modular data models (AKA archetypes; for some examples see in a clinician driven process. These are then used to create other artefacts like UIs.

    Generating forms has been an aim for some time ( and has been achieved in some projects (such as but leveraging on a project like orbeon would certainly save many developer years. Obviously I realise to get there it still needs considerable developer skills and time.

    Unfortunately not a project for a medical doctor with limited development skills like me. Maybe something for a practical thesis...

    Enough day dreaming ;)

  4. Hi Thilo, yes we have thought about this, a number of times, over the years :). But it is a hard nut to crack. There is a sort of independence mismatch between the schema and the form: the schema defines what the data to be captured looks like, while the form definition primarily describes what the UI to do that capture looks like. The hope is that an automated schema-to-form tool would at least save some time to the form author, but it is not clear to me that it really would, and even if it did, that you would end up with a reasonable UI with that approach.

    For now, when designing forms, in most cases it is IMHO best to take a step back, and ask ourselves the question: "what would be the most user-friendly UI to capture this data?", and starts creating it with Form Builder.