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>
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

	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
	implement is to have a form containing both textual and binary
	and require the user to fill out and and submit the form for
	(entry pass) and then allow corrections and final submission
	pass).  But, I want to send the binary data to the server only
	in the "review pass" after all the other data has been
	because uploading the binary data is expensive and costs the
	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
	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
	stages, file upload data is entered during the "review pass"
after the
	initial submission of the other data to the server.  So,
	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
	There are problems with this. The user doesn't see the "same"
	twice, he can't fill in the upload information during the
	pass.  This requires extra smarts on the part of the user as he
	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
	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
	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
	down the line.  Current implementations show the user the
	when choosing a file for upload, so the users review of the
	data is a weak one, but there's no reason the client couldn't
	show some summary of the file content, the document title, an
	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
	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,
	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
	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
	local state with javascript.  The trouble with both these
options is
	backward compatibility with older clients.  The great thing
	(X)HTML is that older browsers may not do the latest wiz-bang
	but if the feature works at all, the application will muddle
	As an application writer I take comfort in that.
	Thank you very much for all your help.  I know much more than
when I
	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
	> 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.
	> 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
	> 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"
	>       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
	>       > 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
	>       > since <upload> in XForms is only about uploading
	>       > data (non-xml data). Since XForms is about XML, let's
	>       > start presuming that your application doesn't require
	>       > upload:
	>       It _is_ binary upload that I'm concerned about.
	>       My understanding of a XML Schema is that it's syntactic.
	> are
	>       plenty of cases where this is not sufficient and e.g.  a
	> database
	>       lookup will be required to validate an entry.  A ledger
	> 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
	> the Art
	>       Dept.  that's allowed to use the Purple Pencil object.
	> accounting
	>       speak an object is a portion [substring] of a ledger
	> 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
	> 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
	> else
	>       it has to. And then allow the user to "preview" his
	> to be
	>       sure he's got it right before you print 10,000
	> (Or
	>       100,000 when you should have printed 10,000!)
	>       As things stand, I don't see how to do this without
	> the
	>       binary data twice, once for the "check" and once for the
	>       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
	> uploads
	>       manuscripts for editorial review using XHTML, and have
the same
	>       problem.)  It's not just bandwidth.  Other resources may
	> 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)
	>       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
	>       > specifically designed to minimize round-trips to the
	>       > 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
	>       > 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
	>       > screen. Both screens have xforms UI controls, the
	>       > screen uses <input> and <select>, the preview
	>       > screen uses <output>.
	>       >
	>       > The UI controls in *both* screens are bound to the
	>       > 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
	>       > and custom error messages for that XML field. The user
	> 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
	> to
	>       > Schema rules. There is no generic technique to look
inside a
	> binary
	>       > file on the client and see whether it make sense
	> escaping
	>       > into special purpose software - the reason why XML is
a good
	> thing
	>       > in the first place. <upload> is only about uploading
	> data in
	>       > XForms. Everything else is handled in XML, and the XML
	>       > instance gets submitted as such via POST to the server
	> 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
	>       >       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
	> 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
	>       >
	>       >       First allow entry:
	>       >
	>       >       Give user form.
	>       >       User enters data.
	>       >       Upon data errors, re-display form with user's
	>       >       Repeat above until no errors.
	>       >
	>       >       Then require submission preview:
	>       >
	>       >       Allow user final review and changes before
	> submission.
	>       >       Upon data errors, re-display form with user's
	>       >       Repeat above until no errors.
	>       >       Accept reviewed data & process...
	>       >
	>       >       This is useful when the forms are large and the
	> complex.
	>       >       Allowing a computer to check for errors and
giving the
	> user the
	>       >       opportunity to preview his submission has two
	> First,
	>       > the
	>       >       user can rely on the computer to catch obvious
	> he does
	>       > not
	>       >       have to review his information for nit-picky
	> 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
	>       >
	>       >       The problem is, this idiom is rather wasteful of
	> bandwidth under
	>       > XHTML
	>       >       1.0 <input type="file">, and I presume XForms
	> (I have
	>       > no
	>       >       experience with XForms beyond a few minutes web
	> browsing, so
	>       > please
	>       >       excuse any ignorance.)  The file/data will be
	> each time
	>       > the
	>       >       user submits the form.  *blech* The upload
should only
	> occur
	>       > after the
	>       >       machine checks the initial submission and user
	> 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
	> standards.
	>       >
	>       >       What springs to my mind is a XHTML <input
	> type="pathname">.
	>       > This
	>       >       would work/render (almost) just like <input
	> but the
	>       > file
	>       >       would not actually be uploaded.  The server
	> would
	>       > change
	>       >       from type="pathname" to type="file" once the
	> validation
	>       > step
	>       >       was passed and the user had previewed the
	>       >
	>       >       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
	> 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
	>       >       value="pathname" type="file"> so that it can
pick up the
	> value
	>       > of the
	>       >       cookie and know what the user had requested to
	> (My
	>       > ignorance
	>       >       of XForms is showing here.  I imagine there's
	> binding to
	>       > XML data
	>       >       somewhere.)
	>       >
	>       >       I hope something can be done (or has been done)
	> 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
	> me.
	>       >
	>       >       Regards,
	>       >
	>       >       Karl <kop@meme.com>
	Karl <kop@meme.com>
Received on Monday, 20 May 2002 11:20:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:06 UTC