Re: XForms not enough

Here's a slightly different perspective (which isn't quite what
w3c had envisioned, but...)

There are a large class of applications that are most easily
modeled as a "flow of control."  Typically these applications
will get some info from the user, do some processing, get some more
info from the user, do some more processing, etc.   (There are other
applications - in general more complex - that better match an event-
based processing model [does that make sense?])

For these "flow-of-control" types of applications, html forms have
been a good match.  The semantics of HTML do a good job of capturing
an application's request for data (as well as the user's response).
Unfortunately, HTML also contains semantics that are particular to
Web Browsers and so isn't a good general mechanism for capturing
these requests.

This is a/another place that i see xforms fitting in - as the a
platform independent descript of an applications request for data
from the user.  Then its a matter of translating the xform into
html/wml/or whatever.  There is absolutely no reason why this 
translation couldn't be made into much more visually interesting
presentation elements (swing, vb, etc).  The only requirement from
the applications point of view is that data is returned that fulfills
the requirements that it requested (with the xform).

We're building this kind of system for one of our clients and had
started to develop this presentation medium independent representation
for requests and responses.  Then along came xforms and it seems like
a perfect fit (unless it heads off in a totally different direction...)
The point: it seems like xforms can be as easily translated into
"thick" clients as thin client.  It may be that the xforms group is
only interested currently in the xforms mapping into html, wml, etc.,
but that doesn't mean that it's not applicable elsewhere...

Dan


Rob McDougall wrote:
> 
> Personally, I don't think you're seeing the bigger picture.
> 
> Your point of view seems to be hinged on three key underpinnings:
> - availability of thick clients
> - if the W3C recommends it, the browsers will follow
> - the W3C should address a need for high complexity web applications now
> 
> On the first point, while the web clients are becoming thicker, more "thin"
> clients are being added every day (phones, TVs, etc.).  XForms has to be
> able to address these devices too.  If we make the functionality of XForms
> dependent on having a rich browser then we forsake the fastest growing
> segment of the web.
> 
> Secondly, browser vendors do not always implement W3C recommendations (how
> many browsers fully support CSS2?).  The XForms recommendation has to be
> attractive to browser implementers as well.  If we pack too much into it
> today, browser vendors may decide that it's too much work and not implement
> any of it.  We need to walk the line between what consumers want and what
> implementers are willing to sign up for.
> 
> Thirdly, you seem to wish to write fully featured applications utilizing
> just a browser in the near future.  While that's a laudable goal, one has to
> walk before one can run.  The technologies you cite (XSchema and XUL) are
> intended for a development audience.  That's not the majority of web
> authors.  The majority of web authors are HTML people.  XForms is aimed
> squarely at this majority.  The HTML authors don't have that ability to do
> rich forms without XForms.  The development audience always has JavaScript,
> as painful as it sometimes is.  Their need (in my opinion) is not as great.
> 
> The XForms recommendation must strike a balance between incrementally
> improving HTML forms and maintaining the ability of implementers to
> implement the functionality with low cost and on all platforms.  XForms must
> also set a path that will eventually lead to where you want to go (rich web
> applications), but we're not going to get there in V1.0.
> 
> Rob
> 
> -----Original Message-----
> From: Joe Hewitt [mailto:jhewitt@zenimax.com]
> Sent: June 9, 2000 11:47 AM
> To: www-forms@w3.org
> Subject: RE: XForms not enough
> 
> I'm really tired of the sort of mediocre technology that we have to work
> with on the web.
> The web absolutely needs an integrated set of application building blocks.
> I'm tired of static, page-driven sites, and the longer we stick with that
> paradigm, the longer it will take for the web to reach the next level of
> productivity.
> 
> It's nice that XForms wants to be a clean extension to HTML.  But HTML
> sucks.  I have a hard time justifying mediocre solutions in the interest of
> lazy developers everywhere. XForms is looking like a mediocre solution.
> 
> Developers shouldn't have to be forced to develop application frameworks
> entirely in Javascript.  Applications built in Javascript can get complex
> and slow enough without having to have the entire framework in Javascript
> too.  If the framework were an open standard, it could be implemented
> natively in all browsers, and we could build apps that really work.  Look at
> Mozilla as an example of this.
> 
> W3C should ask itself these questions:
> 
> 1). Is the web moving towards a thicker client model? Yes.
> 2). Is it good to build a framework to support that model? Yes.
> 3). Is it good to build separate technologies that are kludgy when used
> together? No.
> 
> This leads us to the conclusion that the framework itself should be
> integrated.  I know W3C working groups try hard to work together, and that
> XForms is working with the XSchema group, but before XForms can continue we
> need a working group for an XUL-like language as well.  In fact, I think
> XForms should have one working group for the data model, and another working
> group for the presentation.
> 
> -----Original Message-----
> From: John Ky [mailto:hand@syd.speednet.com.au]
> Sent: Friday, June 09, 2000 1:06 AM
> To: Joe Hewitt
> Subject: Re: XForms not enough
> 
> My understanding of XForms is only cursory but it appears to me that
> XForms will:
> 
> + Need to operate in a heterogeneous environment consisting of devices
> other than web browsers - some with limited capabilities.
> + Be simple to use and migrate easily from HTML Forms.
> 
> XForms cannot loose sight of its audience in the interest of integration.
> 
> Where I would like to see XForms develop is consistency with other
> recommendations to improve interoperability.
> 
> If XUL/XBL could be used to implement the XForms recommendation
> in full (when the recommendation eventuates) then that will surely
> demonstrate the flexibility and extensibility of mozilla.  It would further
> guarantee a high level of integration while maintaining XForms as a
> sufficiently stand-alone technology.
> 
> So my argument is that XForms shouldn't become part of a larger
> project, but it should be designed in a way that maximises its chances
> of being used with or even implemented with other technologies such
> as XUL/XBL.
> 
> -John

-- 
	Daniel Drasin				Applied Reasoning
	drasin@appliedreasoning.com		4711 Ilkley Moor Ln.
	(410)-461-6168				Ellicott City, MD, 21043
	http://www.appliedreasoning.com

Received on Friday, 9 June 2000 19:29:28 UTC