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

RE: xforms:submission with GET but no parameters

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Tue, 27 Jun 2006 11:36:33 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF401F96FDB@usa7061ms01.na.xerox.net>
To: "John Boyer" <boyerj@ca.ibm.com>, "Erik Bruchez" <ebruchez@orbeon.com>
Cc: "www-forms" <www-forms@w3.org>, <www-forms-request@w3.org>
Personally I think that giving an error when there is no bound node at
all is and submitting with no parameters when there are no child nodes
of the bound node is the cleanest solution.
It requires no special cases, and follows naturally from the rest of the
rules in the binding and serialization sections.
I believe that in terms of weighing who has to do the work, giving an
error when the bound node doesn't exist is more beneficial to authors
debugging forms than easing the load of the occasional author who needs
to do something special.
Thank you,
Leigh.
 

________________________________

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of John Boyer
Sent: Tuesday, June 27, 2006 10:32 AM
To: Erik Bruchez
Cc: 'www-forms'; www-forms-request@w3.org
Subject: Re: xforms:submission with GET but no parameters



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/
Received on Tuesday, 27 June 2006 18:37:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:05 GMT