Tag Archives: interoperability

Standards conformance

It’s very tempting sometimes to allow things that the spec doesn’t allow in the interests of usability, but I always put standards conformance first.

–Michael Kay on saxon-help

On the conformance part, we agree in principle, but this is a case where these events as specified by XForms are, we think, pretty useless, and the overhaul would be sorely needed.

–Erik Bruchez on github

After a few days trying to get something out of these refresh events I must say that I have to agree with Erik and find that Orbeon’s proposal makes a lot of sense.

Unfortunately this illustrates why every XForms implementation had to diverge from the recommendation and all the interoperability issues which can be expected in this kind of situation!

Enabling test automation

Most of the usefulness of unit test environment comes from their ability to automate the tests.

With the principles used in this project, automation can be achieved by submitting the tests results once they become available. Translated into XForms terms, this means submitting the results in an action at the end of test  which are themselves triggered by an xforms-ready event .

For server side implementations, using a submission with @replace=”all” makes a lot of sense because the tests can be performed server side without any browser interaction and directly return test results.

The basic feature to enable this is thus the ability to perform submissions with @replace=”all” on xforms-ready events.

This simple repro case checks this ability:

  <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xf="http://www.w3.org/2002/xforms"
    xmlns:ev="http://www.w3.org/2001/xml-events" >
        <title>Submission on xforms-ready</title>
        <xf:model id="model">
            <xf:instance id="instance">
                <data xmlns="">Whatever</data>

            <xf:submission id="echo" ref="instance('instance')" method="POST"
                resource="http://localhost:8088/exist/apps/betterform/sandbox/echo.xq" replace="all"/>

            <xf:send ev:event="xforms-ready" submission="echo"/>

    <body> </body>


Unfortunately this does work with Orbeon Forms but not with betterFORM nor with XSLTForms.

Trying to develop inter-operable XForms applications happens to be very similar to trying to develop inter-operable web applications but just harder: there are no JavaScript libraries to hide incompatibilities, nobody seems to care much and the differences are not documented anywhere!

I have created a page to document XForms interoperability issues, hoping that this work may be useful for others.

To come back to test automation, Orbeon Forms has defined an extension to perform local echo submissions without client/server interactions. With this extension you don’t have to rely on a web service to replace the page by its test instance and that facilitates the development of automated tests running in pipelines.

Of course this won’t be possible with a client side implementation such as XSLTForms and for these implementations we will probably have to run a browser on a virtual screen such as Xvfb.

A simple form reveals four issues

After an idea that came up in the comments on my last post, I have written a simple form to test how xforms-enabled/xforms-disabled events could be tracked to determine the status of controls.

The form did work as expected with Orbeon Forms but doesn’t happen to work with neither betterFORM not XSLTForms and I have sent reports accordingly on  the Betterform-users and xsltforms-support mailing lists.

These issues are really blocking to pursue this idea which would allow to test control’s statuses. I don’t see what can be possibly wrong in the code that I have written and do hope that we’ll find a workaround or get fixes soon.

While doing these tests I have also noticed that betterFORM was not reacting like Orbeon Forms and XSLTForms when changing the selection in xf:select controls: with betterFORM the value is not updated in the instance until the focus leaves the control while it is immediately updated for Orebon Forms and XSLTForms.

Developing mostly for Orbeon Forms this behavior seemed natural to me but the W3C recommendation clearly states that betterFORM is right when there is no @incremental=”true” attribute. Here again I have reported the issues on Xsltforms-support and orbeon-forms.

This second issue is minor and doesn’t really impact XForms Unit but this clearly show what happens when you try to develop forms that should be inter-operable in the three main open source XForms implementation: even simple forms are a nightmare like here where I had to fill four reports!