W3C home > Mailing lists > Public > www-forms@w3.org > September 2000

linking to external xml and xsd sources

From: Schulze, Matthias <schulze@dresden-informatik.de>
Date: Tue, 5 Sep 2000 17:22:40 +0200
Message-ID: <7140E412EB5ED411B8720050BF1123B0037029@www.dresden-informatik.de>
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 GMT

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