W3C home > Mailing lists > Public > www-forms-editor@w3.org > February 2002

Suggestions (final)

From: Plech¹míd Martin <Martin.Plechsmid@merlin.cz>
Date: Fri, 15 Feb 2002 11:33:26 +0100
Message-ID: <E50028F23FC6D3118B7D00609761083F015E7050@merkur.merlin.cz>
To: "'www-forms-editor@w3.org'" <www-forms-editor@w3.org>
Hello.

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

1) In the standard, there are several things that need a cleaner
explanation.
2) I suggest to rename the attribute "ref" on xforms:bind elements to
"nodeset".
3) I suggest to allow the "readOnly" attribute on form controls.
4) 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 would be allowed.
5) I suggest to introduce a grouping element for "xforms:bind"s in
"xforms:model"s.
6) I suggest to allow more than one xforms:instance element in one
xforms:model.
7) I suggest to allow any kind of children for xforms:item.
8) I suggest the xforms:insert doesn't clone the last node in the nodeset
collection, but clones a template instead.

I've met with various problems during my attempts of using the XForms for
advanced forms creation. And I 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:


1) In the standard, there are several things that need a cleaner
explanation.


1a) 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)?
1b) Explain what happens, if the "ref" attribute on a form control refers to
no instance-data node. E.g.

        <xforms:instance>
              <root1/>
        </xforms:instance>

        <xforms:input ref="/root2">
              <xforms:caption>Root</xforms:caption>
        </xforms:input>
1c) Is the "xlink:href" attribute required to be supported on xforms
elements only, or anywhere in the document? In particular, what is supposed
to happen if something like this

        <xforms:instance>
              <root1 xlink:href="dynamic_data.asp" />
              <root2>
                  <static-data-element1 />
                  ....
              </root2>
        </xforms:instance>

appears in the code? Is the XForms processor required to import the
"dynamic_data.asp" file? I suppose not. But if yes, how is such an
xforms:instance to be treated by XPath expressions in "ref" and "nodeset"
attributes?


2) I suggest to rename the attribute "ref" on xforms:bind elements to
"nodeset".

2) The "ref" attribute refers to a single node, but on xforms:bind it
behaves differently - it refers to a nodeset, like the "nodeset" attribute
does.


3) I suggest to allow the "readOnly" attribute on form controls.


3a) At first, the suggested rendering for xforms:output is the same as for
html:span, whereas for xforms:input it is html:input. Therefore,
xforms:output cannot be interchanged freely with readonly xforms:input.
At second, imagine that I have a form (say, for a contract) allowing to fill
in the contract parties into the head of the form, and repeating them at
other places through the form. Then, the form fields for the contract
parties could be read-write in the form head only, everywhere else they
would have to be read-only, but rendered everywhere as html:inputs.
Depending on the answer to 1a), this may not be even possible to accomplish.
Even if it was possible, the way how to do that seems to me unnecessarily
complicated. This is why I suggest to allow putting the "readOnly" attribute
also onto XForms controls. 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>

3b) The second reason for readOnly form controls is simply in that it is
often more natural to put the "readOnly" attribute on a visual element than
on the corresponding instance data.


4) 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 would be allowed.


4) 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:

        <xforms:repeat id="rpt1" nodeset="employee">
              <xforms:group>
                  <xforms:caption>Line no.<output ref="cursor('rpt1')"
/></xforms:caption>
                  .....
              </xforms:group>
        </xforms:repeat>


5) I suggest to introduce a grouping element for "xforms:bind"s in
"xforms:model"s.


5) 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 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 will be
able to use the "common_constraints.xml" file for checking of the posted
data. (Just an idea: 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 could be
interpretted as database columns. The xform would then distribute the data
from the form into the database. But, this itself wouldn't suffice, e.g. an
equivalent of "SELECT ... FOR UPDATE" SQL commands would be needed.)


6) I suggest to allow more than one xforms:instance element in one
xforms:model.


6) Any form control must have a corresponding instance node. Some of them
are initialized from a (server-side) database, others are not. Currently,
one has to write something like this:

        <xforms:model>
              <xforms:instance xlink:href="dynamic_data.asp" />
        </xforms:model>
        <xforms:model>
              <xforms:instance>
                  <static-data />
              </xforms:instance>
        </xforms:model>

But what to do if you want to submit a subset of both the static and the
dynamic instance nodes? As xforms:submitInfo is tied to a single
xforms:instance only and xforms:instance is a singleton in xforms:model,
there's no way of doing this, now. Therefore I suggest to allow more
"xforms:instance"s in xforms:model. E.g.:

        <xforms:model>
              <xforms:instance xlink:href="dynamic_data.asp" />
              <xforms:instance>
                  <static-data />
              </xforms:instance>
              <xforms:submitInfo nodeset="/static-data|/dynamic-data" ... />
        </xforms:model>

Submit would then apply the "nodeset"'s XPath expression to all
xforms:instance elements and join the results together. (I'm aware that
xforms:submitInfo can have the "ref" attribute only, not the "nodeset"
attribute. And I'm aware that this requirement is in order to allow
submitting valid XML documents. But what I have written is only a
suggestion, not a solution.)


7) I suggest to allow any kind of children for xforms:item.


7) 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
that XForms offer, I don't know how to make an XForm that could be
transformed into HTML code 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:

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


8) I suggest the xforms:insert doesn't clone the last node in the nodeset
collection, but clones a template instead.


8a) 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?
8b) 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?


 
Received on Friday, 15 February 2002 07:53:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:10 GMT