W3C home > Mailing lists > Public > www-forms@w3.org > April 2006

RE: Dynamic @action attribute on xforms:submission

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 19 Apr 2006 19:49:30 +0100
To: <www-forms@w3.org>
Message-ID: <02bc01c663e1$ff7113f0$7e01a8c0@Jan>

Hi Erik,

An issue very close to my heart!

> With XForms 1.0 and 1.1 draft, it is not possible to 
> dynamically specify the @action attribute on 
> xforms:submission. However, in these days of REST, it is 
> obviously necessary to be able to do that.

Well, it's not just REST--you can't even do something simple like read an
RSS feed that is defined at run time.

> How have implementors addressed this?

In the absence of something in the spec, we have two different solutions for
our two versions of formsPlayer--attribute value templates in formsPlayer 2,
and the xf:extension element in formsPlayer 1.

> The following solutions come to
> mind:
> o Handle @action as an attribute value template, for example:
> action="http://example.org/app/{instance('my-instance')/image-
> name}/etc"
>    Benefits: very flexible; XSLT does it so we are not reinventing the
>    wheel.
>    Drawbacks: XForms doesn't use attribute value templates anywhere at
>    the moment. Users will expect that avt will work in other places as
>    well!

We use this in formsPlayer 2, and in many ways it's my favoured solution.
However, since you also need to be able to control the method and headers,
we've not used this approach in version 1, and instead went for the rather
laborious, but more powerful, xf:extension technique.

A good example of how complex submissions can get is illustrated in the
following post on our skimstone site:


In it we discuss making a submission to the Backpack API:

  Backpack has three further complicating factors; first,
  your user name is actually used as a sub-domain to
  access your data:


  Second, a specific request header is required--
  X-POST_DATA_FORMAT must be set to xml. And the third
  is perhaps the most complicated--the URLs themselves
  need to be dynamic; for example, to update the content
  of item 5 on page 1234, the URL will be something like:


I would see this submission to Backpack as a kind of test case for a lot of
the features that submission needs, so any solution we devise must include
the ability to set arbitrary headers, as well as compose any part of the
URL. (They don't use a method that is calculated at run-time, but ideally
we'd support that too.)

A submission that works with Backpack that makes use of our xf:extension
feature looks like this (a full working form is included with the entry on
skimstone, mentioned above):

   replace="instance" instance="inst-backpack-response"
          <part value="'http://'" />
          <part value="instance('inst-session-data')/backpack-username" />
          <part value="'.backpackit.com/ws/'" />
value="instance('inst-session-data')/backpack-command-expanded" />
          <header name="X-POST_DATA_FORMAT" value="'xml'" />

Not pretty...but at least it allows us to control every part of a submission
whilst we wait for a solution to be specified.

> o Extra attribute on xforms:submission, such as @action-ref.
>    Benefits: does not introduce avt.
>    Drawbacks: another attribute to remember; requires @action to be no
>    longer required; doesn't scale to other attributes; *-ref attribute
>    names are not nice-looking ;-)

And unfortunately what will probably happen is we then start adding more
attributes in other places that we would like AVTs. Better to just get on
and add AVTs.

> Any other ideas or suggestions?

My favoured approach is AVTs, but I think we should add them generally,
rather than just for one or other feature.



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
Received on Wednesday, 19 April 2006 19:07:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:17 UTC