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 Sunday, 19 May 2002 21:20:36 UTC