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

Re: xforms:submission with GET but no parameters

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Tue, 27 Jun 2006 21:35:48 +0100
Message-ID: <44A196A4.5010807@orbeon.com>
CC: 'www-forms' <www-forms@w3.org>


It looks like there are two issues here:

1. What we do when "no node is selected". This is the erratum you are
    mentioning. Clearly there are a few ways to deal with this:

    o Throw xforms-submit-error, as mentioned
    o Not do anything (like xforms:setvalue, xforms:load, etc.)
    o Perform the submission with no parameters (case of GET only)

2. How do we actually accomplish submitting with GET with no

#1 and #2 are not necessarily related.

What happens when you have neither @ref nor @bind on
xforms:submission? Is this allowed at all? As I said in my initial
email, I thought that not having @ref or @bind was allowed, but that
this would select the root element of the first instance.

If this is in fact not allowed, then a good course of action may be
allow this and:

o Perform GET (and DELETE) without parameters
o Throw xforms-submit-error for all the other methods

This said, it seems to me that we have an issue with URL
parameters. The WG decided probably a long time ago that when
performing a submission with GET, the instance would be passed as
query parameters.

But in fact all the HTTP methods can have query parameters in the URL,
and currently only GET takes them from an instance. Shouldn't DELETE
also have this option? What about POST and PUT?

In theory I think it would be better if there were two attributes on
the submission:

o One to control what is passed as the request body (POST, PUT)
o One to control how to build request parameters (all methods)


John Boyer wrote:
 > Hi Eric,
 > The XForms recommendation, as stated, assumes that a node will be
 > selected.  It does not
 > say what happens on failure to select a node, although that makes the
 > validation rather hard.
 > Due to this, an action item was created to write an erratum to XForms to
 > say that an xforms-submit-error
 > occurs if there is no instance data to submit.  Since it was an erratum,
 > it ended up on my plate.
 > So, I performed that action item some time ago, and the result appears
 > in the erratum list,
 > the full spec and even the thin spec available from our website.
 > In fact, for 1.1 I even updated it so that the errorname says no-data
 > I see from your email that you have a use case to the contrary of the
 > erratum.  This is fine.
 > I will add this email to the list, and if the use case is accepted, then
 > I would ask that you please
 > consider taking the action item to make the necessary changes in the
 > submit default processing
 > to account for having no data.
 > It might be best to limit this to method=get, yes?
 > I would think two or three of the bullet points must change, not just
 > the one containing the submit-error.
 > I believe that the thin spec changes will differ from the errata/full
 > spec.  However, we are hoping to
 > publish an updated thin spec working draft and updated errata document
 > on July 12, so
 > getting the work done before then (allowing time for integration) would
 > be helpful.
 > Thanks,
 > John M. Boyer, Ph.D.
 > Senior Product Architect/Research Scientist
 > Co-Chair, W3C XForms Working Group
 > Workplace, Portal and Collaboration Software
 > IBM Victoria Software Lab
 > E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
 > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
 > *Erik Bruchez <ebruchez@orbeon.com>*
 > Sent by: www-forms-request@w3.org
 > 06/27/2006 05:27 AM
 > To
 > 	"'www-forms'" <www-forms@w3.org>
 > cc
 > Subject
 > 	xforms:submission with GET but no parameters
 > All,
 > Under "11.1 The xforms-submit Event", I read that:
 >   "A node from the instance data is selected, based on attributes on
 >   the submission element. The indicated node and all nodes for which
 >   it is an ancestor are considered for the remainder of the submit
 >   process. Any node which is considered not relevant as defined in
 >   6.1.4 The relevant Property is removed."
 > So it looks like there is an absolute requirement, for a submission,
 > to select a node in an instance (the spec doesn't say what happens if
 > the single-node binding points to a non-existing node). This is done
 > through either @ref or @bind on the xforms:submission element (and I
 > assume that if both are missing we get the root element of the first
 > instance).
 > But there are cases where you don't want to actually submit any
 > instance data in a submission when using the GET method.
 > For example, I may simply want to perform an instance replacement by
 > loading the URL located in the @action attribute.
 > Also, with XForms 1.1, it will be possible to dynamically update the
 > submission action, and with REST, you will often use this to build
 > URLs that only consist of a path, such as:
 >   http://example.org/bookmarks/ebruchez.
 > The way I have been working around this is to use a dummy instance and
 > to say @ref="instance('dummy')". But this is ugly and non-intuitive:
 >   <xforms:instance id="dummy">
 >     <dummy/>
 >   </xforms:instance>
 >   <xforms:submission id="update-bookmarks"
 >     ref="instance('dummy')"
 >     method="get" action="/bookmarks/ebruchez}"
 >     replace="instance" instance="bookmarks"/>
 > So did I miss something, or do we in fact have to use such a
 > workaround when using GET to create a URL that does not have any
 > request parameters?
 > If I am right, then I think we should address this soon.
 > -Erik
 > --
 > Orbeon - XForms Everywhere:
 > http://www.orbeon.com/blog/

Orbeon - XForms Everywhere:
Received on Tuesday, 27 June 2006 20:36:06 UTC

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