RE: Form function and presentation - Schema usage

This summary by Josef is very very good --
to echo his key statement --
"it's not the syntax that makes things hard or difficult
--it's the thinking required--"

after many struggles with attempting to develop a simple
syntax for data models,
we realized that the HTML level author didn't just want a
"simple data model syntax"
--ideally, he/she did not want to think about the data model
at all--
this is why we designed the three tier separation of
concerns you see in XForms today--
it allows the designer of types and models to focus on his
forte whilst allowing UI designers to work on what they do
best.
Separation of concerns *is* a good thing.
--no point in asking some one who only wants to pedal a bike
to go fly a 747.

>>>>> "Josef" == Josef Dietl <josef@mozquito.com> writes:

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

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

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

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

    Josef> You will find the details of the solution in the
    Josef> next draft, roughly what we've done is a tiered
    Josef> approach: - if you don't know about validation,
    Josef> don't worry - you don't have to provide it.  - if
    Josef> you do, you may live with just Schema Datatypes
    Josef> (part 2).  - if you have a Schema, use it.  - if
    Josef> you have someone who knows how to handle Schemas,
    Josef> work with him: the interface between the UI and
    Josef> 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,
    Josef> incremental knowledge is perfectly
    Josef> sufficient. The simplest cases are of the order
    Josef> "/address/street", and while this is news for
    Josef> many, it is sufficiently easy to learn - and
    Josef> whatever else we could have come up with would
    Josef> have been new, too. In that case, you can start
    Josef> out simple and slowly increase your
    Josef> knowledge. Alternatively, you can use the bind
    Josef> element and have someone else do the legwork for
    Josef> you.

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

    Josef> XPath is currently the only know-how bottleneck.

    Josef> With all due respect, but tasked with writing
    Josef> something for XML I take XML for granted, and
    Josef> tons of Web designers have managed to master CSS
    Josef> so far. You can live well in an XForms context
    Josef> without knowing anything about Schemas, it just
    Josef> shouldn't surprise you that you can't access
    Josef> 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.

    Josef> ... and that's why we have kept a very small set
    Josef> of forms-specific properties: required, relevant,
    Josef> readOnly, calculate and validate. It's simply not
    Josef> worth inventing a whole new syntax (plus the
    Josef> learning effort everybody would have to put in)
    Josef> 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).

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

    Josef> If we provide the feature, we want people to be
    Josef> able to depend on it.  Otherwise, we can drop it
    Josef> 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).

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

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

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

    Josef> Hope this helps...

    Josef> Josef

-- 
Best Regards,
--raman
------------------------------------------------------------

IBM Research: Human Language Technologies
Phone:        1 (408) 927 2608
Fax:        1 (408) 927 3012
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Friday, 17 August 2001 20:29:37 UTC