RE: Form function and presentation - Schema usage

Hello Joern,

> 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.

The current perceived gap is IMO mostly an editorial issue (nothing
against our editor here :-): We have removed the simple syntax when we
knew that we couldn't sustain it, but we hadn't had the replacement yet.
A joint task force was founded between the Schema Working Group and the
XForms Working Group, and that task force has delivered its results
recently. We are currently preparing a new draft that among others fills
the gap. Usual disclaimers apply, from what I can see holdig your breath
is in order.

> - 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.

True, Schema is said to be complicated. But looking closely we found
that
 - given our requirements, the thinking process is the difficult part,
the actual syntax is "just syntax". Maybe we could have simpliefied the
syntax, but we could never have simplified the thinking.
 - we have to support Schemas anyway. Simply because the use case that
someone has a Schema for his or her data already is so overwhelmingly
significant.

Essentially, there are two dominant use cases, probably with not much in
between:
 - the really-simple form, say, a search form. Doesn't need input
validation to begin with.
 - the user interface to an XML-based application. In all likelihood,
already has a Schema: the Schema attached to the application in the
background.

You will find the details of the solution in the next draft, roughly
what we've done is a tiered approach:
 - if you don't know about validation, don't worry - you don't have to
provide it.
 - if you do, you may live with just Schema Datatypes (part 2).
 - if you have a Schema, use it.
 - if you have someone who knows how to handle Schemas, work with him:
the interface between the UI and the Schema is as lean as can be.

> - 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 ...

From what I see, the main requirement is XPath, and ever there,
incremental knowledge is perfectly sufficient. The simplest cases are of
the order "/address/street", and while this is news for many, it is
sufficiently easy to learn - and whatever else we could have come up
with would have been new, too. In that case, you can start out simple
and slowly increase your knowledge. Alternatively, you can use the bind
element and have someone else do the legwork for you.

Again, it's not the solution that is difficult but the problem that is
hard, and by using XPath we have at least the people who know about
XPointer and the people who know about XSL-T on our side. We also leave
the door open for future developments in the area of XPath together with
XML Query, which is a extremely exciting prospect to me. Ideally, one
day in the future, your form fields could adress directly into the
database...

XPath is currently the only know-how bottleneck. 

With all due respect, but tasked with writing something for XML I take
XML for granted, and tons of Web designers have managed to master CSS so
far. You can live well in an XForms context without knowing anything
about Schemas, it just shouldn't surprise you that you can't access
Schema's features in that case.

> - 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
> syntax.

... and that's why we have kept a very small set of forms-specific
properties: required, relevant, readOnly, calculate and validate. It's
simply not worth inventing a whole new syntax (plus the learning effort
everybody would have to put in) just for these five properties.

> - 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).

Interesting approach. But as far as I can tell, it is difficult to
realize and will not provide an XForms author with the necessary
reliability. For example, if (s)he writes a form and assumes that the
model takes care of checking that a date-of-birth is actually a date,
then a translation to DTDs will just not cut it. Faced with that
prospect, the designer would have to write the code for the date
validation again anyway, so under these circumstances the model doesn't
add value.

If we provide the feature, we want people to be able to depend on it.
Otherwise, we can drop it in the first place.

> - 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).

As I said earlier: the tricky thing is not the markup, the tricky thing
is the thinking behind. Repeat and switch are extremely powerful
constructs, and exploiting that power takes some thought. A switch in
the UI for example is pretty much equivalent to a choice in the Schema,
and repeat corresponds to maxOccurs>1. So, fundamentally, it's easy. But
you can nest and recurse these constructs - that is where the power
comes from, but it's also where the brainware is challenged.

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

You're welcome. Live and learn - and what I personally start to realize
is that XForms is so powerful that it's hard to keep the general
overview. The benchmark is still the saying from the old XML guru: Make
the simple things simple and the hard things possible. (I've heared this
first from Paul Grosso, but I'm not sure he is the originator.) In my
opinion, we stick with that by providing reasonable defaults for
everything. What do others think?

Hope this helps...

Josef

Received on Friday, 17 August 2001 09:01:19 UTC