W3C home > Mailing lists > Public > www-forms@w3.org > May 2002

Re: XHTML/XForms limits "preview submission" idiom

From: Sebastian Schnitzenbaumer <schnitz@mozquito.com>
Date: Mon, 20 May 2002 17:19:55 +0200
Message-ID: <D0F1529EE943B3449F755CA1A40887465B3EE7@winserver.windomain.mozquito.com>
To: "Karl O . Pinc" <kop@meme.com>
Cc: <www-forms@w3.org>
Karl,
 
couple of things. The idea about sending the pathname of
the file upload entered at entry time to the server and then
again showing a thumbnail at review time is a bad one
because of security problems. You can't fetch a web page
that tries to access local data, ie. two different host domains.
 
The only exception here is the file upload widget, because
the user agent (browser) can assume that this has been
done by the user himself explicitly. 
 
So if entry pass and review pass would be in a single local
state instead of two, this would be possible, since the browser
still "knows" at review pass that the user himself has explicitly
selected a file from his local hard drive at entry pass. And this
can be done with XForms, even without SOAP. SOAP
really doesn't add too much.
 
Your problem is a common one. I myself designed a web
application in 1996/1997 which had the exact same problem.
The only solution I found was doing two round-trips, just
a you said, and thanks to a security whole in Netscape 3
back then, I could trick the browser to display a local image
entered on a form page before. :-)
 
XForms should really solve this problem, since XForms
allows you to share local state across any series of screen
pages. From an implementation point of view, my company is 
currently working on an XForms implementation that works 
in existing browsers. We've long gone the automatic
markup-to-JavaScript transcoding technique on the
server-side, and have now switched to a markup-to-Flash
technique. The browser needs to have the Flash 6 plug-in
installed, then you can author XForms in pure XML form
and our software makes sure it gets transcoded into Flash,
so you never have to author Flash directly, just XHTML
with XForms.
 
- Sebastian
 
 
-----Ursprüngliche Nachricht----- 
Von: Karl O . Pinc 
Gesendet: Mo 20.05.2002 03:27 
An: Sebastian Schnitzenbaumer 
Cc: www-forms@w3.org 
Betreff: Re: XHTML/XForms limits "preview submission" idiom



	Hi,
	
	I'm not sure we're both talking about the same thing, which
means I'm
	confused about something.  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'm
going to
	contact the XHTML folks because I feel I know what I'm talking
about
	regarding XHTML and see what they say to my question.  Then I
may get
	back to XForms.
	
	I see it is _possible_ to do what I want with XForms, if there
is way
	to keep state on the client.  What I don't understand is how I,
as an
	application writer, know that SOAP is available on the client,
any
	more than I know that javascript is available.  (All I know
about SOAP
	is that it's an XML data transfer protocol, and maybe more
besides.
	To interoperate applications must share a Schema.  I've no clue
how to
	invoke it.)  Clearly the XForms/SOAP solution is most efficient.
If I
	_had_ to have something work today, I imagine I could hack up
some
	local state with javascript.  The trouble with both these
options 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.
	
	Thank you very much for all your help.  I know much more than
when I
	started.
	
	On 2002.05.19 17:27 Sebastian Schnitzenbaumer wrote:
	> Karl,
	>
	> the XForms draft does not forbid handling and sending multiple
	> instances to the server. So if it is anything object-oriented,
	> including XHTML, you could send partial XML for
	> validation without loosing state on the client. In an
implementation
	> this could be implemented via SOAP.
	>
	> Data such as image and audio data cannot be validated except
	> for showing it twice to the user. This could also be done
	> by an XForms implementation, ie. the spec precludes it.
Nothing
	> is wrong about storing binary data in an XML node, and
	> referencing that node from both an <upload> and <object> or
	> <img> tag. The implementation then has to handle spooling in
the
	> right viewer for that binary data installed on the client. No
	> round-trip would be used.
	>
	> It is a question of implementation, not of XForms as a markup
	> language, as I understand it. X-Smiles is just a testbed, but
	> functionality-wise almost XForms feature-complete. Other
	> implementations will follow. XForms will eventually become
	> a part of XHTML. XHTML questions are raised on
	> www-html@w3.org, see: http://www.w3.org/Markup ;-).
	>
	> Let the W3C know if you find more problems and ideally
	> solutions to XForms and XHTML.
	>
	> - Sebastian
	>
	>
	>
	>
	>       -----Ursprüngliche Nachricht-----
	>       Von: Karl O . Pinc
	>       Gesendet: So 19.05.2002 22:44
	>       An: Sebastian Schnitzenbaumer
	>       Cc:
	>       Betreff: Re: XHTML/XForms limits "preview submission"
idiom
	>       
	>       
	>
	>       On 2002.05.19 07:16 Sebastian Schnitzenbaumer wrote:
	>       > Karl,
	>       >
	>       > let me help you. First, there is a place to discuss
this, the
	>       > www-forms@w3.org mailing list, see how to subscribe
at:
	>       > http://www.w3.org/Markup/Forms/
	>       
	>       Thanks very much for your reply and the mailing list
pointer.  I
	> don't
	>       know how I missed it.
	>       
	>       >
	>       > Now to your question. I'm a bit confused about
<upload>,
	>       > since <upload> in XForms is only about uploading
binary
	>       > data (non-xml data). Since XForms is about XML, let's
	>       > start presuming that your application doesn't require
binary
	>       > upload:
	>       
	>       It _is_ binary upload that I'm concerned about.
	>       
	>       My understanding of a XML Schema is that it's syntactic.
There
	> are
	>       plenty of cases where this is not sufficient and e.g.  a
	> database
	>       lookup will be required to validate an entry.  A ledger
account
	> number
	>       is an example.  I don't see a Schema containing an
entire chart
	> of
	>       accounts, so there's no way it's going to know that it's
only
	> the Art
	>       Dept.  that's allowed to use the Purple Pencil object.
(In
	> accounting
	>       speak an object is a portion [substring] of a ledger
account
	> number.)
	>       
	>       So, to cook up an example, suppose you've a form
submitting some
	> name
	>       and address stuff, a ledger account number, and the 3
different
	> image
	>       files that define the CYK color plates needed to print a
page of
	>       advertisement.  It'd be nice to let the user fill out
the entire
	>       form. Then have the server check the account number and
anything
	> else
	>       it has to. And then allow the user to "preview" his
submission
	> to be
	>       sure he's got it right before you print 10,000
advertisements.
	> (Or
	>       100,000 when you should have printed 10,000!)
	>       
	>       As things stand, I don't see how to do this without
uploading
	> the
	>       binary data twice, once for the "check" and once for the
final
	>       submission.  Or rather, I do see how to do it, but it
takes a
	> small
	>       addition to the standards.  This is what my question
below is
	> all
	>       about.  (In the real world, I'm writing an application
that
	> uploads
	>       manuscripts for editorial review using XHTML, and have
the same
	>       problem.)  It's not just bandwidth.  Other resources may
be
	> consumed
	>       to generate the binary data.  If you're scanning, why
wait for
	> the
	>       scanner to scan twice?
	>       
	>       If I understand the probem, the solution (see below)
seems
	>       straightforward for XHTML as well as XForms.  Even if
XForms can
	>       handle this (feel free to tell me to read the
instructions.  I
	> can
	>       imagine XForms dispatching an XML submit event that
POSTs just
	> the
	>       account number (XML) to the server for validation.) it
would be
	> nice
	>       if XHTML had a solution available too.  Is there another
group I
	>       should be writing to about the XHTML?
	>
	>       > In this case, you're an XForms customer. :-) XForms
was
	>       > specifically designed to minimize round-trips to the
server.
	>       > Look at X-Smiles, http://www.x-smiles.org
	> <http://www.x-smiles.org> , a really good
	>       > XForms implementation.
	>       
	>       Looks neat.  (I fear the BSD style licence dooms it to
	>       marginality. :-( )
	>       
	>       >
	>       > How it works: In XForms you can define multiple views
	>       > onto the same XML data. We have introduced the
<switch>
	>       > UI element, which allows multiple UI views, or
screens, or
	>       > cards to be shown to the user based upon events.
	>       >
	>       > So with <switch> you can write an XHTML page that has
	>       
	>       > two screens, the input screen, and the preview
submission
	>       > screen. Both screens have xforms UI controls, the
input
	>       > screen uses <input> and <select>, the preview
submission
	>       > screen uses <output>.
	>       >
	>       > The UI controls in *both* screens are bound to the
same
	>       > data in the XML data instance via xpath:
	>       >
	>       > Screen1:
	>       > <input ref="mydata/address/firstname" />
	>       >
	>       > and
	>       >
	>       > Screen2:
	>       > <ouput ref="mydata/address/firstname" />
	>       >
	>       > When the user changes the value in the input screen,
the XML
	>       > instance defined at the <head> of the HTML page:
	>       >
	>       > <head>
	>       > <xform>
	>       >   <instance>
	>       >      <mydata>
	>       >        <address>
	>       >           <firstname>NewValueEnteredByUser</firstname>
	>       > ....
	>       >
	>       > changes and since the <output> controls are bound to
the same
	>       > node in the XML instance, the next screen
automatically has
	> the
	>       > updated value.
	>       >
	>       > Then, using XML Schema datatypes, you can add input
validation
	>       > and custom error messages for that XML field. The user
will
	> get
	>       > an error message in both screens if he enters an
invalid value
	>       > according to the rules defined by the Schema.
	>       >
	>       > This is all happening on the client in XForms.
	>       >
	>       > The tricky thing about <upload> is, that binary data
cannot be
	>       > validated on the client, since it is not XML and does
adhere
	> to
	>       > Schema rules. There is no generic technique to look
inside a
	> binary
	>       > file on the client and see whether it make sense
without
	> escaping
	>       > into special purpose software - the reason why XML is
a good
	> thing
	>       > in the first place. <upload> is only about uploading
binary
	> data in
	>       > XForms. Everything else is handled in XML, and the XML
data
	>       > instance gets submitted as such via POST to the server
when
	> the
	>       > user hits submit.
	>       >
	>       > Hope this helps,
	>       >
	>       > - Sebastian
	>       >
	>       >
	>       >
	>       >
	>       >       -----Ursprüngliche Nachricht-----
	>       >       Von: Karl O . Pinc
	>       >       Gesendet: So 19.05.2002 08:32
	>       >       An: tmichel@w3.org
	>       >       Cc: steven.pemberton@cwi.nl; Sebastian
Schnitzenbaumer
	>       >       Betreff: XHTML/XForms limits "preview
submission" idiom
	>       >
	>       >
	>       >
	>       >       Hi,
	>       >
	>       >       I have a problem with a XHTML design limitation
that I
	> also
	>       > believe is
	>       >       in XForms.  I expected to find a mailing list to
submit
	> this to,
	>       > but
	>       >       all I could come up with was your addresses.
Please let
	> me know
	>       > if I
	>       >       should send this note somewhere else.  Thanks.
	>       >
	>       >       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.  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.
	>       >
	>       >       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.
	>       >
	>       >       Regards,
	>       >
	>       >       Karl <kop@meme.com>
	
	Karl <kop@meme.com>
	
	
Received on Monday, 20 May 2002 11:20:44 GMT

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