W3C home > Mailing lists > Public > www-forms@w3.org > August 2001

Was: Form function and presentation - Schema usage

From: joern turner <joern@webman.de>
Date: Wed, 15 Aug 2001 06:01:30 -0400 (EDT)
To: www-forms@w3.org
Message-ID: <3B7A4922.80207@webman.de>
Hello Josef,

Josef Dietl wrote:

 > Hello Michael,
 > first of all, my apologies for the slow response, it is vacation time
 > all over XForms-land.
 > You appear to have fairly ambitious goals with your forms handling. As
 > XForms is developed in a W3C contect, it is probably more useful to move
 > to the bigger W3C framework in order to answer your questions:
 > First, XForms is completely based on XML Schema. Schema is the future,
 > and the more we dive into developing XForms, the more we realize that it
 > would have been impossible to build based on DTDs. Besides, DTDs just
 > don't offer the content validation features that we want.

completely agreed.

but: ;)
the former WD still defined a 'Simple Syntax' for defining
XForms-models,which was removed in the last WD. For my personal opinion
this was an unlucky move...
Let me explain:
- it may be a personal issue but the removal left a gap which makes it
harder to imagine how the pieces (model,instance,ui) fit together. i
finally returned to a kind of 'simple syntax' for internal processing.

- Schema is surely the future, but also terribly complicated for a
novice. The use of Schema directly in XForms raises the bar of knowledge
a XForms-Editor needs by degrees. The Simple Syntax provided a nice way
to reduce that markup-complexity and ease the job of XForms-editing.

- all this terrible flexibility XForms provides should also serve simple
purposes. The effort of building a simple form application (like all
these thousands in the web) with XForms shouldn't be much higher than
the conventional way of hacking html-forms and perl-scripts. At the
moment an editor needs knowledge of XML, CSS, Schema, XPath ...

 > That said, even Schemas don't provide validation to the extent you
 > propose. So we have introduced an additional constraint, an attribute
 > called validate that is attached to the data item. The value of that
 > attribute is a predicate that needs to be satisfied for the associated
 > instance data item to be considered valid. That would be a place where
 > you can express "date of birth < date of death". Anything that you can
 > stuff into an XPath expression that evaluates to a boolean, roughly. So:
 > probably not sufficiently sophisticated for your credit card example,
 > but fairly close. For the complex cases, you will still need a small bit
 > of script.

- as you've mentioned even Schema doesn't provide some features e.g.
there is no direct mapping of a required attribute. These additional,
form-specific issues could be more clearly marked out in a specialized

- a lot of the power of XForms comes from its abstractions: e.g. the UI
abstracts a concrete representation in a UI-toolkit. Why not let the
model abstract the concrete usage of a schema (with little s) mechanism?
This would nicely solve the issue with different clients: like the
processor maps the UI to the clients-format it could map a XForms
model-syntax to a version compatible with the client (may it be Schema,
Relax,T-Rex, DTD, instance-attributes,..., according to needs).

- we've been building some test-forms with repeats and switches and even
in our simplified syntax, the appropriate model-markup becomes really
complicated (we're using just one element where Schema syntax needs at
least 3).

Thank you for considering these argruments. They are directly related to
our pratical problems while implementing a constrained client (pure html).

Joern Turner

 > Josef
Received on Wednesday, 15 August 2001 07:09:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:04 UTC