RE: [XForms] XForms and InfoPath

Yes, you are correct in assuming that we are "completing" rather than
"abandoning" our integration of XForms into our product.  Previously we
had our own XML vocabulary for creating platform independent forms with
much of the same intention as XForms.  We were glad to see the
introduction of XForms, which enables us to move towards a standard.
Forms of course are an important means of gathering information and
enabling users within an organization to complete their work as part of
any given business process.  Most BPM/Workflow solutions force process
designers to choose a technology dependent representation of the form at
design-time (using Active-X, JavaBeans, HTML, or other proprietary
method).  We utilized our own platform independent XML vocabulary to
store the definition of a form, enabling the form to be rendered using
different technologies.  But we were missing a few features such as
event handling, flexible validation and control similar to repeats.
Furthermore, the form data model was tied closely to the definition of a
process, making it difficult to use our forms outside of our run-time
environment.  For us XForms has the advantages of :

1)       being a standard

2)       Our users can plug in third-party tools to render our forms.

3)       Enables our forms to be self-contained (can be emailed around
and worked on my multiple people before being submitted)

4)       Forms are now reusable across process types in an application
(due to forms having their own data model).

5)       Like or forms previously, XForms are platform independent and
will enable our users to view their forms through various devices.

 

XForms are deeply integrated into our 5.0 release.  Once a form is
defined using our form designer it can be associated to any given step
in a process (All defined within our Process Application Design PAD
tool). At run-time we provide APIs to retrieve the form definitions
based on the context of where you are at in the process.  In addition,
the workflow engine stores and tracks changes to the instance data.  We
also have our own XForms processor that utilizes Javascript/DHTML/XSL to
render the XForms at run-time within our web-client (but can also be
used outside of our framework).  At design-time, the form design
utilizes XForm components (XFCs) to build the form definition.  These
XFCs are pluggable and provide a design-time representation to the form
designer while generating XForms content at run-time.

 

 

More information will be available as we approach our release date,
which is towards the end of May.

 

Shone Sadler

 

-----Original Message-----
From: AndrewWatt2001@aol.com [mailto:AndrewWatt2001@aol.com] 
Sent: Monday, April 14, 2003 6:39 AM
To: www-forms@w3.org
Subject: Re: [XForms] XForms and InfoPath

 

In a message dated 13/04/2003 23:02:42 GMT Daylight Time,
ssadler@qlinktech.com writes:





At my company we are in winding down our 5.0 release which fully
integrates XForms into or core workflow engine, replacing our
proprietary forms implementation. 



Shone,

I assume you mean "winding down" as in "completing" rather than "winding
down" as in "abandoning"?

I would be interested to learn more of how you weld XForms to your
workflow app.

We did take a look at MS's Infopath and we liked two things about it 1)
It was a 



nice design tool for forms and 2) it was part of the MS Office suite,
which will of course help it to proliferate.  I do feel that success
with InfoPath will drive the demand for XForms.



Yes, I think the notions thrown into relief by both InfoPath and XForms
are similar. The potentially very important thing is that if InfoPath
and XForms do what they have the potential to do then business
efficiency will be improved.

I am not pretending that such issues are easy to solve, but from a
business point of view they are important to solve/improve.

  We do see an opportunity in using InfoPath as another means of
rendering 



XForms defined within our product.  From what I saw, Infopath did seem
to be overly complex.  Not from the form designer perspective, but from
the programmatic aspect.  There did not seem to be any
"language/vocabulary" for Infopath, instead it relied upon code
generation (mainly XSLT). Generating XSLs, XSDs, XML (default data), and
one meta-data file all within one zip file.  Also there did not seem to
be any way of having a self contained form defined in one file, since
the XML instance data was always a separate file that referenced the ZIP
file through a URL.





Interesting observations.

Microsoft have a track record of sometimes not getting version 1.0 quite
right but, for important products at least, making substantive
improvements in later versions.

Maybe MS will include XForms in InfoPath 2.0?

Andrew Watt






Shone Sadler