RE: Levels of XForms (was: RE: Form function and presentation - Schema usage)

Joern,

while Sebastian is completely right, I have one more detailed question
that I wouldn't want to be lost:

In your message, you allude to easier ways of expressing switch and
repeat. Can you elaborate?

Thanks in advance,

Josef

> -----Original Message-----
> From: Sebastian Schnitzenbaumer 
> Sent: Tuesday, August 21, 2001 2:58 PM
> To: joern turner; www-forms@w3.org
> Subject: Levels of XForms (was: RE: Form function and presentation -
> Schema usage)
> 
> 
> Joern,
> 
> you know what? I think the points you make are
> absolutely valid and need further consideration
> by the Working Group.
> 
> I don't see us go down the path again to define
> yet another "Simple Syntax" for the model. Been 
> there, done that. It is also important to point
> out that whilst your points in favour of such
> freedom for the model part in XForms are totally
> valid (really!), others do favour a concrete 
> permutation of the model defined in the spec.
> 
> If we as the W3C XForms WG go down the path of
> specifying a concrete model for XForms, we are
> obliged to re-use existing W3C technology - that
> is just the way it is - therefore we have to take 
> a subset of Schema (XForms Basic) or Schema as it 
> is (XForms Full). We simply don't have the 
> freedom of defining a completely "self-contained" 
> XForms spec - and I think that makes total sense 
> too: to build upon tested, pre-existing 
> components instead completely re-inventing the
> wheel.
> 
> However, as I said, you have some valid points:
> If you have to "break the spec" to make an
> "xformisch" implementation happen, and for
> resource reasons you cannot even implement 
> the schema subset simply because of the verbose
> syntax - we have to take this serious.
> 
> Would the following solve your problem:
> 
> We define a new level of XForms conformance next
> to the two existing ones:
> 
> XForms Core: The basic XForms concept of 
>   Model-View-Controller, the binding mechanism
>   and the core XForms module(s) (<xform>, <model> &
>   <instance>). You may yourself choose and use any 
>   pre-existing or custom model language and any
>   UI language as well as of course any arbitrary
>   XML instance for data.
> 
> XForms Basic: XForms Core + Concrete Model as 
>   W3C XML Schema Subset (Part 2 Datatypes) 
>   + XForms UI.
> 
> XForms Full: XForms Core + Concrete Model as 
>   Full W3C XML Schema + XForms UI.
> 
> 
> Food for thought. Others on this list: Opinions?
> 
> Thanks,
> 
> - Sebastian
> 
>  
> > -----Original Message-----
> > From: joern turner [mailto:joern@webman.de]
> > Sent: Tuesday, August 21, 2001 10:48 AM
> > To: www-forms@w3.org
> > Subject: Re: Form function and presentation - Schema usage
> > 
> > 
> > Hello Josef,
> > 
> > excuse my late reply (but my collegues and me are actually in the
> > deadline for delivering a basic, working 'XFormish' 
> implementation, so
> > that's why) and thanx for your detailed reply but it seems 
> to me that
> > maybe i somewhat haven't made clear our/my intensions:
> > 
> > let me try to clarify...
> > 
> > Josef Dietl wrote:
> > 
> >  > 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.
> > 
> > 
> > 
> > i think i understand the status of a Working Draft but as 
> > i've committed
> > to the basic ideas of XForms and try to deliver a xformsish 
> > ;) thing as
> > soon as possible,  we had to 'guess' something in the 
> > meantime in order
> > to meet this goal (and adapt later). we would be happy to 
> integrate a
> > well-defined Schema syntax as soon as it's fixed.
> > 
> > 
> > Our struggles/experiences with down-to-the-ground problems of the
> > implementation brought up some differences/extensions to the 
> > current WD
> > and i've tried to transfer these back...
> > 
> > 
> >  > 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.
> > 
> > 
> > Agreed, the thinking is the hard part - but after thinking 
> > when it comes
> > to implementation efficiency and real-world constraints 
> > (limitations in
> > clients/protocol/robustness of tools) are the other. sure, it's only
> > syntax but it even brings a reasonable powerful machine 
> into sweat if
> > you implement all this server-side. so why hang the apple so
> > un-necessarily high?
> > 
> > if you're really reject the idea of an 'abbreviated syntax' you
> > should better skip the following, but i think there are arguments ;)
> > that go much beyond.
> > ---
> > everything in the following is induced through some kind of 
> real-world
> > constraint that exists TODAY, so some issues will solve 
> through newly
> > delivered technology in the future while other issues will 
> > remain. some
> > can be overcome with common solutions while others may not. 
> to list a
> > few when you want to deliver for today:
> > 
> > - support for CSS is in most cases either incomplete and unreliable.
> > this makes the layout part in XForms hard.
> > 
> > - only really advanced clients can deliver the 'XForms Full' 
> > conformance
> > level in networked applications - with DOM-Events, the
> > 'immediate'-functions and such. this implies use of RPC of 
> > some kind and
> > some really serious processing...
> > 
> > - ... or the use in an stand-alone client. but which client 
> could not
> > network today, if it's so powerful, that it can deliver full XForms
> > processing?
> > 
> > - ...otherwise the client must understand XML. unluckily it's likely
> > that for some time (maybe one maybe two years, doesn't 
> > matter) from now
> > it will be senseless to send XML directly to your client, cause they
> > will not or only partially understand it.
> > 
> > - so it maybe not completely wrong to assume a 'devided' 
> > architecture to
> > become common: some processing and advanced functions 
> server-side and
> > styling, interactivity, simple validation client-side for example.
> > 
> > - a lot of clients rely on http for simple to medium, even complex
> > networked applications today and is IMHO one of the most interesting
> > environment for XForms-processing, cause http often is used 
> > not only for
> > browsers but for small devices too. but unfortunately this 
> > leads to all
> > this well-known (and already mentioned) problems which i 
> don't want to
> > repeat here.
> > 
> > 
> > the 'abbreviated' syntax lowers the memory consumption of our 
> > processor
> > by degrees through the simple fact that we use three times 
> > less tags for
> > expressing the same semantics; the memory consumption slowly reaches
> > acceptable sizes: one testcase contains one example for most of the
> > XForms UI elements and is about 500 lines of XML. these would 
> > have been
> > easily about at least the double in full Schema syntax.
> > 
> > - this memory consumption has naturally some unwanted effects on
> > processing-time, searches and evaluations on the tree.
> > 
> > - fully! Schema-aware, robust and open technology will be some time
> > away, as is common support for CSS, XPath, XML, XSL on the client
> > (sorry, if i repeat myself)
> > 
> > 
> >  >
> >  > 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.
> > 
> > 
> > i'm really looking forward to that!
> > 
> > 
> >  >
> >  > 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.
> >  >
> > 
> > 
> > i don't really intended to make this an 
> > 'all-or-nothing'-case. for one,
> > i widely agree that new technologies offer new possibilities 
> > but for the
> > price of learning. we are in the lucky situation to have all these
> > xml,xsl,Schema,xpath, java expert ready, so that's not the 
> problem to
> > us. but even then the solution should scale to meet a wide 
> > range of needs.
> > 
> > second, but i believe that a spec also gains through
> > 'self-containedness' - maybe one reason why html was 
> adapted so fast.
> > 
> > 
> >  >>- 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.
> >   >
> > 
> > absolutely.
> > 
> > on the contrary a transformation from an internal 
> > representation to some
> > kind of client-schema allows some advanced uses:
> > 
> > consider following scenario:
> > a client connects to a server and requests an XForms 
> session. through
> > user-agent recognition the server may fetch a XForm and the 
> > appropriate
> > transformation for the client. for the server a 
> > transformation to Schema
> > will be used to validate the incoming-data. for the client another
> > transformation will map all validations that the client 
> > supports into an
> > appropriate schema syntax and transfer it to it. this 
> allows to reduce
> > the contacts during the form-filling session and allows to 
> delegate at
> > least some immediate validations to the client.
> > 
> > to cut it short it would allow to plugin a schema mechanism into the
> > processor may it be Schema (very likely in the future), some 
> > lightweigth
> > mechanism to support PDAs,DTDs when your application just 
> > requests that.
> > just imagine to map even to database-models directly. this way a
> > processor could also export different model-representations for
> > data-consumers.
> > 
> > 
> > this scenario has surely some more interesting aspects which
> > 
> > allow a flexible adaptation to the clients capabilities and 
> would go 
> > beyond all-or-nothing.
> > 
> > 
> > 
> >  >
> >  >>- 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.
> >  >
> > 
> > 
> > the power of XForms is why we committed us to it and i can 
> only agree
> > that it really challenged us but we managed to walk through all this
> > recursions and get it running but not without the price of 'breaking
> > some rules' of the spec.
> > 
> > with all respect for the WD and their authors, i can only sum up our
> > experience: it's not only the thinking it's also the thinking 
> > of how to
> > implement it!
> > 
> > 
> > Joern
> > 
> > 
> >  >
> >  > Josef
> >  >
> >  >
> >  >
> > 
> > 
> > 
> > 
> > 
> 
>

Received on Tuesday, 21 August 2001 09:23:07 UTC