- From: Schulze, Matthias <schulze@dresden-informatik.de>
- Date: Tue, 5 Sep 2000 17:22:40 +0200
- To: "'www-forms@w3.org'" <www-forms@w3.org>
hi all, I've got some basic questions about the new XForms requirements WD: 1) schema accordance This is another vote for XML Schema support: The "XForms Working group will utilize functionality from XML Schema ..." [cite]. Does that mean that the XForms model syntax is *different* from XML schema? The example in the XForms data model WD looks alot like XML schema, so I hoped you wouldn't invent something new. A "lighwight syntax" won't help to reduce the crowd of dialects and languages at all... And in m.O. the problem of supporting XML Schema is not one of the "typical HTML autors" but one of the user agent vendors! Personally, I believe that the presentation of a XForm should always be consistent with the schema. For instance, if the Schema constrains an element to a known set of values, the user agent should be free to present a simple <input ...> like <select ...> and so on. That means that the schema should take precedence over the form definition. 2) linking to model and instance are the model and instance elements required to appear in the XForm document itself or can they be linked to like this ??? <model src="http://www.schema-provider.net/purchaseOrder.xsd"/> <instance src="http://www.data-provider.net/purchaseOrder.xml"/> As XForms "will be designed to cleanly distinguish between form instance data, form description ... and form presentation" [cite] this should be no problem. If we can link to the instance data, we can put a servlet behind that url and query a database and output the xml! But it brings up a whole bunch of new requirements like a) selecting subsets of the instance data : <instance src="http://www.data-provider.net/purchaseOrder.xml" where="purchaseOrder/shipTo[name]='Alice Smith'"/> b) resolving concurrent updates / locking: <instance src="http://www.data-provider.net/purchaseOrder.xml" where="purchaseOrder/shipTo[name]='Alice Smith'" for-update="true" /> c) re-ordering instance-data d) caching instance data at client-side / persistence of cached data 3) server-side processing In section 3.4. of the new XForms Req. you say that Xforms sends the form data back to the server. How shall the server handle these data? If the server processes it through the standard form-action (perhaps a perlscript), the connection between the source of the data and the local copy at the client is lost. Thus we couldn't establish locking mechanisms and such... In my opinion the XForms user agent should rely on *server facilities* allowing it to *modify* the submitted data at server-side. This could be done through XSL styles that are generated by the user agent an processed by the server against the source of the instance data. 4) sorting A XForms user agent should be able to re-sort the instance data on user's request without contacting the server. - - - well, aparently I misunderstood some conceptual things, but I hope it takes the whole thing a little bit further anyway. Finally, I want to complain that the example in the XForms Data Model WD is once again about placing an order. I hope that XForms will not only optimize *this* matter. Retrieving and editing information is a much more sophisticated process that XForms should deal with nicely. As I see it now, XForms continues to rely on bs like MS ASP to query a database generate a document. greetz - Matthias ____________________________________________ Matthias Schulze phone: +49 351 82665 0 Dresden Informatik GmbH fax: +49 351 82665 55 D-01099 Dresden www: http://www.dresden-informatik.de Tannenstrasse 2A e-mail: schulze@dresden-informatik.de
Received on Tuesday, 5 September 2000 11:25:23 UTC