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

RE: xforms and wokflow?

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Fri, 19 Aug 2005 12:14:05 +0100
Message-ID: <8085DB71-F5C2-4E2A-8295-06B42F16780B@S009>
To: <jeacott@hardlight.com.au>
Cc: <www-forms@w3.org>

Hi Jason,

Once people move beyond basic forms to serious applications, then the most
common questions they raise concern workflow. For example, we are working on
a substantial project for a customer where they have a complex workflow
defined. But at various points that workflow needs to retrieve information
from users. The question becomes, should the workflow pause and give the
user a large form, let them fill it in and then only move on when it has the
complete results? Or should the workflow break the task into sub-tasks, and
therefore give the user many smaller forms -- one for names and addresses,
one for the product they want to buy, a different one depending on whether
they are a smoker or a non-smoker...and so on.

The latter seems to fit more with how people consider workflow engines at
the moment, but the former is by far the better experience for the user, and
actually easier to manage for the developers.


USER EXPERIENCE
Treating the whole thing as a high level task gives the user a better
experience, since they can then do things like work offline. Filling in a
tax return, for example, is the type of thing you might need to do
disconnected from a server, since it can take a while. (And it's certainly
the kind of thing you *wouldn't* want to do in a traditional HTML form.)


DEVELOPMENT
It's also easier to manage, since a lot of functionality is encapsulated in
the form, which means that you have flexibility in using different back-end
systems. One of the (many) really powerful things about XForms is that it
talks nice and easily to REST and web services systems, meaning that your
'back-end' gets very clean -- once you have produced the web services that
you need, you're more than half-way done.


But that of course brings us to your specific question; you are saying that
given XForms can express so much of our workflow, why would we want add a
further layer to get BPEL to orchestrate? I agree. XForms actually has much
of the functionality that you would need to synchronise various actions in
the way that you describe. And given that it has an eventing model it is
extremely flexible compared to other workflow languages.

But all I can say is that, today, we are not there yet. There is work
underway on the XForms Working Group to make the submission side into a
separate specification that could stand alone. This will take us a long way
in the direction you want, since it could easily be implemented in
non-client systems.

And what you would also need would be for XForms to have the ability to be
'paused' whilst waiting for external input, such as an email. This is
something we are working on with formsPlayer -- in particular the idea of
having a list of forms that are at various stages of completion.

So although I'm giving you bad news for today -- you probably need to use
your workflow engine to orchestrate the things you have described (although
I would reflect the status back to a form, so that XForms is still in the
driving seat) -- I think the things you are describing are a 'must have' for
XForms in the future, and I can certainly say that we plan to help make sure
they are implemented over the coming period.

Best regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

> -----Original Message-----
> From: www-forms-request@w3.org 
> [mailto:www-forms-request@w3.org] On Behalf Of Jason Eacott
> Sent: 19 August 2005 04:37
> To: Sikora, Gary
> Cc: www-forms@w3.org
> Subject: RE: xforms and wokflow?
> 
> 
> ok,
> 	so if I were using formfaces (it shouldn't make any 
> difference) then how would you approach the problem?
> 
> thanks.
> 
> 
> Subject:        	RE: xforms and wokflow?
> Date sent:      	Thu, 18 Aug 2005 23:49:08 -0400
> From:           	"Sikora, Gary" <gjsikora@progeny.net>
> To:             	<jeacott@hardlight.com.au>
> 
> > Try ForeFaces and we can help ... Cleaner approach ... No division 
> > between server-side and client-side processing ...
> > 
> > Very respectfully,
> > Gary Sikora, FormFaces Product Manager
> > 
> > -----Original Message-----
> > From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On 
> > Behalf Of Jason Eacott
> > Sent: Thursday, August 18, 2005 22:51
> > To: www-forms@w3.org
> > Subject: xforms and wokflow?
> > 
> > 
> > Hi,
> > 	heres a use case I have to implement, and I'd sday its 
> a very common 
> > scenario. I already have an xform that can define and build simple 
> > xforms (an xform builder form :)  ).
> > the forms it builds can submit the data to any number of email 
> > addresses and optionally send it to a data sink too (it 
> always sends 
> > it to the sink if no email addresses are assigned)
> > 
> > ok - so now I have to implement a simple workflow into the system.
> > after one of these generated forms (just a plain old xform 
> - we could 
> > have started the story here but I thought some background 
> might help - 
> > hope it doesnt confuse) is made it gets used.
> > when a user fills in a form and submits the data, that data 
> needs to 
> > be approved before it is stored/emailed. it may need to be 
> approved by 
> > multiple folk, so using a workflow engine would make sense.
> > 
> > is there any way to intercept the processing of an xform so 
> that I can 
> > accept the submission, send out other emails for 
> confirmation on other 
> > forms, and then somehow ask an xform to complete its tasks.
> > I can see how I might have one form that just submits, then do some 
> > serverside logic for the workflow , get another form for 
> answers, then 
> > just write code serverside to dump  the data into the sink, 
> and send 
> > off the various email responses if the data is approved, 
> but how could 
> > I achieve this last part by letting the xform do all that 
> (because it 
> > already knows how to) I may have an advantage that I am 
> using chiba - 
> > serverside xforms implementation, so perhaps I could 
> instantiate half 
> > a form serverside or something.
> > I run across this kind of thing all the time with xforms, I 
> don't want 
> > to break up my simple definition of what data should go where - it 
> > works well all described in a simple xform, I just want to 
> insert some 
> > workflow before it completes. how can i do this kind of 
> thing without 
> > getting REALLY ugly?
> > 
> > any thoughts appreciated.
> > thanks
> > Jason.
> > 
> > 
> 
> 
> 
> 
Received on Friday, 19 August 2005 11:14:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:01 GMT