- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 27 Jun 2006 14:46:35 -0700
- To: Erik Bruchez <ebruchez@orbeon.com>
- Cc: www-forms@w3.org, www-forms-request@w3.org
- Message-ID: <OFC9F8701F.F1454338-ON8825719A.00761654-8825719A.0077A023@ca.ibm.com>
Hi Eric,
A few notes:
1) A submission with no ref or bind is already defined to select the
document element of the default instance, so we can't use that as a
mechanism for doing a zero-data GET.
2) A ref to empty node-set in submission should not act like setvalue,
etc. It is safe that they don't act the same because a submission isn't an
action. The problem there is that do nothing means literally no-op, which
is not what you want the submission to do anyway.
3) The new <resource> element can be used to allow instance data to be
used to populate URL parameters for post, put and delete calls, so we can
probably contain this problem to the original issue you raised, which is
that of having zero parameters for GET (and DELETE).
As to the exact nature of the solution, I think both you and Leigh are
correct.
I believe Leigh is correct that we shouldn't change our minds about ref to
empty node being allowed for GET and DELETE. This feels too much like a
hack. Imagine explaining to your user who wants to do a simple GET that
they have to add a ref to a non-existent node to make it work. This is
almost as bad as having them create a dummy instance.
But I believe you are certainly correct that the feature needs to be there
and needs to be easy (in fact the above is really saying that it needs to
be easier than ref to empty nodeset). This is a good catch, and I look
forward to seeing it in there. In fact, I went looking through the action
item list because I really thought that this came up at the November
face-to-face. We've got a couple of broken links at the moment that will
soon be fixed, so I can't confirm this, but I believe Mark Birbeck
proposed solving this problem via an attribute called serialize that, when
set to false, would simply not construct the submission serialization. So
the submission would proceed without the serialization, based either on
the action attribute content or the new <resource> element child of
submission.
If I am right about the nature of the resolution to add a serialize
attribute, then it will just be a matter of getting the action item to be
performed against thin spec, and I have done a lot of structural evolution
of thin spec recently to make this easier to do.
Best regards,
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 01:35 PM
To
www-forms@w3.org
cc
"'www-forms'" <www-forms@w3.org>
Subject
Re: xforms:submission with GET but no parameters
John,
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
parameters.
#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)
-Erik
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:
http://www.orbeon.com/blog/
Received on Tuesday, 27 June 2006 21:46:53 UTC