suggestions

Hello.

I was pointed here by Micah Dubinko to propound here my suggestions. Here
they are:

0) I suggest to rename the attribute "ref" on xforms:bind elements to
"nodeset".
1) I suggest to introduce a grouping element for "xforms:bind"s in
"xforms:model"s.
2) I suggest to allow the "readOnly" attribute on form controls.
3) I suggest to allow the "required" attribute on form controls.
4) In the standard, there are several things that need a cleaner
explanation.
5) I suggest that the "ref" attribute on xforms:output element be an
arbitrary XPath expression, not necessarily returning a node, but also a
string or number.
6) I suggest to allow more than one xforms:instance element in one
xforms:model.
7) I suggest the xforms:insert didn't clone the last node in the nodeset
collection, but cloned a template instead.
8) I suggest to allow any kind of children for xforms:item.

I've met with various problems during my attempts of using the XForms for
advanced forms creation. And found that I'm currently unable to solve them
(effectively, or at all) without extending the XForms namespace with my own
elements/attributes, or even without modifying the XForms elements'
behaviour. It is not important to me that the problems I'm mentionning will
be solved the way I suggest, but that the problems will be reflected and
XForms will provide means to solve them somehow (elegantly).

I appreciate the work you all have done concerning XForms. I'm sorry I have
to say that, but it seems to me, that the XForms specification still needs
many important things to be solved, without which a serious XForms usage
would be unimaginable. In my opinion, it is too early for the specification
to become a standard, because once it becomes a standard, things can't be
changed, only extended.

Best regards,
			Martin Plechsmid.



Details:

4a) Does the "readOnly" constraint on instance data mean that the
corresponding form controls are to be readonly, or that the instance-data
value cannot be changed at all (nor by means of xforms:setValue)?
4b) Explain what happens, if the "ref" attribute on a form control refers to
no instance-data node. E.g.

	<xforms:instance>
		<root/>
	</xforms:instance>

	<xforms:input ref="/employee/name">
		<xforms:caption>Name</xforms:caption>
	</xforms:input>
4c) podpora xlink:href jen na xforms elementech, nebo i jinde? Co pak na to
XPath?

1) The data being submitted have to be checked both at the client and the
server sides. At the client side, they have to be checked in order to
prevent the user from submitting a form that would be rejected by the
server. At the server side, the server cannot trust the client, and
therefore has to check the submitted data again. It seems as a reasonable
requirement that both the client and the server use a shared constraints
file. (Of course, the client (server) can have even other constraints that
don't apply to server (client).) E.g. something like this is needed:

	<xforms:model>
		<xforms:instance>
			<employees />
		</xforms:instance>
		<!-- constraints on the instance data shared with the server
-->
		<xforms:binds xlink:href="common_constraints.xml" />
		<!-- constraints specific for the client side only, used
esp. for the comfort of the user -->
		<xforms:binds>
			<xforms:bind ... />
			......
		</xforms:binds>
		<xforms:submitInfo ... />
	</xforms:model>

And on the server side, there will be a verification mechanism that is able
to use the "common_constraints.xml" file for checking of the posted data.
(E.g. an extended version of XForms language could be used on the server
side for this purpose. The instance data would be the same as those posted
from the client, and the xforms:input elements would be interpretted as
database columns. The xform would then distribute the data from the form
into the database. This itself wouldn't suffice, e.g. an equivalent of
"SELECT ... FOR UPDATE" SQL commands would be needed.)

2a) The first argument for this requirement is simply that it is often more
natural to put the "readOnly" attribute on the visual element than to make
readOnly the instance data. (Also compare 4a above.) E.g.:

	<xforms:model>
		<xforms:instance>
			<contract>
				<party1>
					<name>The First Insurancy
Company</name>
					...
				</party1>
				<party2>
					<name />
					...
				</party2>
		</xforms:instance>
		<xforms:bind ref="/contract/party1//*" required="yes"
readOnly="yes" />
		<xforms:bind ref="/contract/party2//*" required="yes" />
	</xforms:model>

	<html:p>The contract between <html:br />
		<xforms:input ref="/contract/party1/name">
			<xforms:caption>Name</xforms:caption>
		</xforms:input>
		......
	and <html:br />
		<xforms:input ref="/contract/party2/name">
			<xforms:caption>Name</xforms:caption>
		</xforms:input>
		......
	</html:p>

	........

	<html:p>The insured party <html:br />
		<xforms:input ref="/contract/party1/name" readOnly="yes">
			<xforms:caption>Name</xforms:caption>
		</xforms:input>
	and the insurer
		<xforms:input ref="/contract/party2/name" readOnly="yes">
			<xforms:caption>Name</xforms:caption>
		</xforms:input>
	agree that.....
	</html:p>

You may object that I could have used xforms:output elements instead of
readOnly xforms:input elements. But this might be true only for this
particular example, a better conceived example could show the need for using
xforms:input more clearly. Moreover, the default rendering for xforms:output
is the same as for html:span, whereas for xforms:input it is html:input.

2b) The second reason for readOnly form controls comes from the way how the
xforms are to be processed:
When a client opens a form, initial instance-data values are read from the
server (database). But the form has to contain instance-nodes also for those
form-controls (e.g. auxiliary form controls), initialization values for
which were not read from the server. E.g.

	<xforms:model id="init-data">
		<xforms:instance xlink:href="data.asp" />
	</xforms:model>
	<xforms:model id="aux-data">
		<xforms:instance>
			<root>
				<total-expenses />
				......
			</root>
		</xforms:instance>
	</xforms:model>

	<xforms:repeat model="init-data" nodeset="/expenses/payment">
		<xforms:input model="init-data" ref="." />
	</xforms:repeat>

	<xforms:input 



3) If a constraint on instance data is violated, the user must get a
reasonable explanation that allows him to correct the cause. But imagine the
situation when to a required attribute corresponds no form control (i.e. it
is invisible).


5) Suppose I have a xforms:repeat, and I want to number the lines in the
resulting table. I imagine I would write something like this:

	<repeat nodeset="employee">
		<group>
			<caption>Employee no.<output ref="position()"
/></caption>
			.....
		</group>
	</repeat>

7a) Currently, the specification requires xforms:insert action to clone the
last element in the "nodeset" collection. But what if the collection is
empty and I'm inserting its first element?

7b) Imagine I have a list of <person> elements with information about their
children (name, age). Imagine that the last person in the collection has
three children; its record can look like this:

	<person name="John smith">
		<children>
			<child name="Mary" age="5" />
			<child name="David" age="3" />			
			<child name="Peter" age="2" />
		</children>
	</person>

Now, if I want to insert another person, the structure with three <child>
elements will get cloned. But what if the new person has only one child?

8) Combining xforms:selectOne/xforms:selectMore with xforms:switch and
xforms:toggle I can achieve HTML code like this:

	<H3>Method of payment:</H3>
	<P>
		<INPUT type="radio" name="r1" value="1" panel="p1">
credit-card<BR>
		<INPUT type="radio" name="r1" value="2" panel="p2"> direct
payment
	</P>
	<DIV id="p1" class="panel">
		<input type="text" name="credNumber"> Credit Card number
	</DIV>
	<DIV id="p2" class="panel">
		<input type="text" name="address"> Your address
	</DIV>

(The panels that are not selected would be hidden.) But, using the means
XForms offer, I'm unable to make an XForm that could be rendered like this:

	<H3>Method of payment:</H3>
	<INPUT type="radio" name="r1" value="1" panel="p1"> credit-card
	<DIV id="p1" class="panel">
		<input type="text" name="credNumber"> Credit Card number
	</DIV>
	<INPUT type="radio" name="r1" value="2" panel="p2"> direct payment
	<DIV id="p2" class="panel">
		<input type="text" name="address"> Your address
	</DIV>

that is to attach the panels to the corresponding radio controls. Therefore,
I suggest to allow in XForms something like this:

	<selectOne>
		<caption>Method of payment</caption>
		<item>
			<caption>credit-card</caption>
			<value>1</value>
			<input>
				<caption>Credit Card number</caption>
			</input>
		</item>
		<item>
			<caption>direct payment</caption>
			<value>2</value>
			<input>
				<caption>Your address</caption>
			</input>
		</item>
	</selectOne>

Received on Thursday, 14 February 2002 10:29:32 UTC