XHTML/XForms limits "preview submission" idiom

Hi,

I have a problem with a XHTML design limitation that I also believe is
in XForms.

The short summary of what I'm trying to implement is to have a form
containing both textual and binary data, and require the user to fill
out and and submit the form for preview (entry pass) and then allow
corrections and final submission (review pass).  But, I want to send
the binary data to the server only once, in the "review pass" after
all the other data has been validated, because uploading the binary
data is expensive and costs the user time.  This is also acceptable in
that the binary data is unlikely to be "bad", at least in a way that
the server can detect, and all the data is validated upon final
submission anyhow.

At present (XHTML 1.0), this can't be done.  The "nearest
approximation" is to have the user enter data into the form in two
stages, file upload data is entered during the "review pass" after the
initial submission of the other data to the server.  So, "regular"
data gets two reviews from the user, the second after a round trip to
the server, while binary data gets only one, before the final upload.
There are problems with this. The user doesn't see the "same" form
twice, he can't fill in the upload information during the "entry"
pass.  This requires extra smarts on the part of the user as he must
recognize that the "review" pass requires him to both review what he
has entered and enter more information.

My question to the w3 is why can't I allow the user to input the data
all at once, identifying uploaded files by pathname, and have only the
pathname make the round trip, and then submit the binary data for the
final upload?  This would give the user a single "pass" at data
entry/review and then another review/correction pass.  I'd like to
know why this is a bad idea, or why it's a fair idea but shouldn't be
incorporated into the standards because there's better ideas a-comin'
down the line.  Current implementations show the user the pathname
when choosing a file for upload, so the users review of the binary
data is a weak one, but there's no reason the client couldn't also
show some summary of the file content, the document title, an image
thumbnail or whatever, if the implementation so chose.

I see it is _possible_ to do what I want with XForms, _if_ there is
way to keep state on the client. The trouble is backward compatibility
with older clients.  The great thing about (X)HTML is that older
browsers may not do the latest wiz-bang stuff, but if the feature
works at all, the application will muddle through.  As an application
writer I take comfort in that.  For these reasons I'd like to see
something done in XHTML.  (I imagine this would then have to also
carry through to XForms.)

What follows is another description of the problem, and my stab at
a solution.  For more on this, see:
http://lists.w3.org/Archives/Public/www-forms/2002May/0017.html
(Link is to my attempt to discuss with the XForms folk, where
I found I don't know enough XForms to communicate effectively.)

-----------------------<snip>-----------------------
I use a common idiom when accepting input from a user:

First allow entry:

Give user form.
User enters data.
Upon data errors, re-display form with user's input.
Repeat above until no errors.

Then require submission preview:

Allow user final review and changes before actual submission.
Upon data errors, re-display form with user's input.
Repeat above until no errors.
Accept reviewed data & process...

This is useful when the forms are large and the data complex.
Allowing a computer to check for errors and giving the user the
opportunity to preview his submission has two benefits.  First, the
user can rely on the computer to catch obvious errors, he does not
have to review his information for nit-picky problems.  Second,
requiring the user to preview a submission known to be acceptable to
the machine allows the review process to be focused on content and so
improves the quality of the information submitted.

The problem is, this idiom is rather wasteful of bandwidth under XHTML
1.0 <input type="file">, and I presume XForms <upload>.  (I have no
experience with XForms beyond a few minutes web browsing, so please
excuse any ignorance.)  The file/data will be uploaded each time the
user submits the form.  *blech* The upload should only occur after the
machine checks the initial submission and user makes final
corrections.

I'm not a XHTML master or even familiar with XForms, but I don't see a
solution to this problem in the current or proposed standards.

What springs to my mind is a XHTML <input type="pathname">.  This
would work/render (almost) just like <input type="file"> but the file
would not actually be uploaded.  (But the pathname chosen by the user
would be passed as the value part of the control-name/current-value
pair.)  The server cgi/script would change from type="pathname" to
type="file" once the machine validation step was passed and the user
had previewed the submission.  This would produce the form presented
to the user for final review.

I would think the same principle could be applied to XForms.  <upload>
would have a type=final|preliminary.  "final" would be the default and
would actually upload.  "preliminary" would deliver a magic cookie to
the server (the pathname in the case of a file upload) that could be
passed back to the client and used by <upload type="final"> to
actually upload.  Naturally <upload> would have to have something
analogous to the 'name' and 'value' of <input name="foo"
value="pathname" type="file"> so that it can pick up the value of the
cookie and know what the user had requested to upload.  (My ignorance
of XForms is showing here.  I imagine there's some binding to XML data
somewhere.)

I hope something can be done (or has been done) to address these
concerns.  Don't hesitate to contact me if you've any questions.

I'd love to hear back from you if you've already addressed this issue,
but don't expect you to spend any of your time educating me.

Sorry for the long post.  I've done a lot of writing on this and I
seems to make sense to include it here in the hopes I won't have to do
even more explaining.

Regards,

Karl <kop@meme.com>

Received on Sunday, 19 May 2002 22:01:48 UTC