- From: Sebastian Schnitzenbaumer <schnitz@mozquito.com>
- Date: Mon, 20 May 2002 17:19:55 +0200
- 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 UTC