several XForms ideas

Hello.

We've been using XForms for some time, and we've met with many difficulties
if using the XForms working draft literaly. We had to solve these
difficulties with our own XForms extensions, or by modifying the required
behaviour slightly where the standard is not clear enough.

I'd like to share some of our ideas with you hoping that they will be taken
into consideration before the final version of the draft is published. The
ideas are maybe trivial, or you may already have taken decision concerning
these issues in the working group - several months have past already - but
even in this case I hope they will be of some use to you.

1. Constraints
==============
In the current XForms specification, binds serve for three different
purposes:

- They put dynamic constraints on instance data: specify relations between
values (calculate), specify whether a part of the xml tree is constant
(readOnly) or relevant. In this case, binds substitute in a sense for a
functionality missing in xml schemas. Indeed, when instance data are
submitted, the server must re-check not only the validity of the document
against the schema, but also the relations between values, or to know that
some parts of the xml tree are omitted only because they are not relevant.

- They specify dynamic behaviour of the model: The "calculate" attribute
says that a value should be updated if another value changes; The readOnly
attribute specifies that some nodes cannot be changed from UI (nor from
anywhere else, in the current specification).

- They have influence on how the UI is presented: Form controls tied to
readOnly nodes are not editable; if tied to nodes marked as not relevant,
the form controls are hidden or grayed out.

It seems to me that mixing these three roles together in one element is not
a fortunate solution. I often need to have a node with calculated value that
shouldn't be modifyable from UI; form controls that are not editable, though
there exist another form controls tied to the same node that can be edited;
forms re-usable at various places and thus containg parts that are hidden in
some situations, even though the tied instance nodes are not irrelevant;
etc.

Thus, we decided to split the whole form into several layers and treat them
separately:

- Each model is a self consistent unit and distinguishes between
modifications from inside and from outside (i.e. from UI or from another
model via setValue). Even though a node is marked as readOnly, it is always
read-write from inside the model. (Remark: A simple analysis of the model
can then show whether a readOnly="true()" node is really constant during the
life-time of the instance, or whether its value could be changed from inside
the model.)

- If a node is readOnly, it is not modifyable from outside the model. The
form controls tied to readOnly nodes cannot be editted. That is, the
readOnly attribute is a part of the model's interface to the outer world.

- The presentation layer consists, of course, of form controls. Form
controls themselves can have attributes "readOnly" and "relevant",
independently on the same attributes inside models. A form control is not
editable if either the tied node is readOnly, or if it is itself marked as
readOnly (calculated values are permitted). I think that these constraints
should be inheritted (i.e. if a group is marked as readOnly, every form
control inside it is considered readOnly).


2. ref vs. value
================
If accepting the "layered" form model, it is natural not to require to have
an auxiliary node in an auxiliary model for any calculated value. Thus, the
form elements that cannot update a node (like "output" or "caption") could
have the "value" attribute instead of "ref", as like as the "setValue"
element. E.g.:

  <xf:output value="if(/a/b, /a/b, '-- not available --')" />


3. submitInfo
=============
Clicking on an (html) link causes only one request to a server. Hence, if a
form requires several kinds of information, they need to be combined into a
single response. All these data we put into the "main" model, thus a single
model instance contains, in fact, several different documents (with a common
root element). Similarly, when submitting the form, I might need to submit a
branch from more than one of these documents. It would help if the
submitInfo element could have the "nodeset" attribute instead of "ref". I
only don't know how to specify the name of the root element of the resulting
xml message. The "ref" attribute could still serve for submition of complete
xml documents.

Another reason why it is necessary to be able to send more than one branch
is that if something gets wrong at the server (e.g. the form is not filled
correctly), the user needs to have the form restored in the same state as
before submition. That is, the server will send the data it obtained back to
the client, and the data need to contain all the partial documents.


4. validation
=============
If only a part of an instance is being submitted, only this part needs to be
validated, not the rest of the form (which is required by the current
specification). I understand that the contemporary xml parsers cannot
validate a xml document only partially. That is why I'm thinking about
prohibitting the "ref" on submitInfo completely. But a _reasonable_
replacement is needed! (Take into account also the way how the form data is
exchanged between client and server, which I partly described above in the
point 3.)


Best regards,
		Martin Plechsmid.

Received on Monday, 27 May 2002 02:38:03 UTC