RE: Cancel a submission in progress

Allan,

On point 1, I will look forward to the submission spec; I'm still hoping
to be able to contribute.

On my point 2, I was unclear and your interpretation is what I meant to
say.  When I said "we need to return error documents", I meant that the
form author and service author needs to design their applications not to
rely on HTTP level errors for reporting conditions to the user, but must
instead return XML error descriptions with code 200, and then code the
form to present them.

On my point 3, xforms-value-changed may occur more frequently than
desired if I read the rec correctly.
Did you think that group/action[@ref='xyz' &
@event='xforms-enabled]/load would be wrong?  It seems to be the closest
to the author's intent, as the relevance of 'xyz' can be set with
bind/@relevant by the form author.  Using
output[@event='xforms-value-changed'/load limits the control to a single
instance node, which means the determination of the condition to do
redirect is back on the instance document generating side (server), and
if that's the case we might as well just have the server calculate the
whole URI.

Leigh.

-----Original Message-----
From: Allan Beaufour [mailto:beaufour@gmail.com] 
Sent: Friday, April 07, 2006 1:40 AM
To: Klotz, Leigh
Cc: www-forms@w3.org
Subject: Re: Cancel a submission in progress

> 1. xforms-submit-error is signalled both when submission fails to 
> happen and when the server responds with a failure.
> The two cases are indistinguishable for the form, and that leads to 
> mayhem, as I noted on April 3rd, 2006:
> >From: Leigh.Klotz@xerox.com
> >Subject: RE: What to do with a 404 on a submission replace="all"?
> >On a related topic, I wish there were a way to distinguish
> server-reported errors
> >such as the 404) from processor-generated errors (such as missing
> required fields).
> >Presumably this will come with the context info, but it would 
> >probably
> be useful
> >even to separate them at gross level.  As it is, a form that catches 
> >xforms-submit-error can't do much with it.  And if the processor
> reports
> >validation or required field errors on its own (such as by 
> >highlighting missing fields), then the xforms-submit-error is a true
annoyance.

I agree, that we should have a way to figure out whether the submission
error was cased by the processor or the server returning an error. In
general it's quite hard to figure out what went wrong in submission, if
something fails. Hopefully some of this will be part of the submission
spec.?

> So my conclusion is that intentionally sending back HTTP error codes 
> is just not a good practice with XFOrms 1.0, and instead we need to 
> return error documents.

That's entirely up to the form/service author, isn't it? If the form
author uses a wrong URI, a 404 would probably occur, no matter what.

> 3. So far so good, but what happens if you want to offer a new page 
> instead of a new view (i.e., you really want to change your mind and 
> do a replace=all with a new URI).  How can you perform xf:load 
> differently in the two cases without putting the new resource URI into

> the returned instance, which inappropriately mixes data and
presentation?
>
> Is xforms-value-changed or xforms-enabled supposed to work for this?

xforms-value-changed should work I think. In theory, maybe not in
practice :)

--
... Allan

Received on Friday, 7 April 2006 17:18:15 UTC