W3C home > Mailing lists > Public > www-forms@w3.org > October 2003

RE: [XForms] Re: Will Internet Explorer support XForms

From: Karandikar, Shailesh <Shailesh.Karandikar@dendrite.com>
Date: Fri, 10 Oct 2003 07:46:08 -0400
Message-ID: <3101F58237A7CF468D6F1DB16778EB6204E2A759@diexus1.us.drte.com>
To: AndrewWatt2001@aol.com
Cc: www-forms@w3.org

I have to agree with you that model used by Infopath is quite useful.
Besides legal/security issues, I would classify 'forms' market into
enterprise and internet. Standards compliance is necessary for internet
class of applications. For enterprise apps, the focus is more on business
logic, workflows, end-user conveniences, efficient manipulation of remote
and local data, multiple views of the same data, compatibility with other
applications such emails, word processing, etc. In other words, rich client
functionality is desirable. 
There is an overlap between the two, but, as it stands now, I don't believe
XForms completely qualify being a rich client (although its a smart
client!). Comparing the two, Infopath styled applications may be more
suitable for enterprises. However, the principles embodied in XForms could
be (and might have been used in Infopath) used in wider context and not only
limited to browsers.

Shailesh Karandikar 
Dendrite Intl.

-----Original Message-----
From: AndrewWatt2001@aol.com [mailto:AndrewWatt2001@aol.com]
Sent: Friday, October 10, 2003 7:31 AM
To: MSeaborne@origoservices.com
Cc: www-forms@w3.org; XForms@yahoogroups.com
Subject: Re: [XForms] Re: Will Internet Explorer support XForms


I notice that you didn't respond to my point:

>How does the UK insurance industry propose to handle the types of legal
issue which >John Messing mentioned in the "How secure is XForms?" thread?

Am I correct in assuming that your old system didn't cover that nor does the
new? Do legal requirements in the UK and USA differ?

In a message dated 10/10/2003 11:58:48 GMT Daylight Time,
MSeaborne@origoservices.com writes:


>>I think whatever the differences in functionality are between 
>>InfoPath and XForms, for many organisations it all boils 
>>down to who owns the underlying technology. The industry I work for
>>(UK Life Insurance) already has its own forms markup language widely
>>deployed, using both client rendering software specific to the 
>>language, and server-side transforms to HTML. This is working today, >>and
has been for several years. We operate in a world where a form
>>may be deployed in many different ways, and by organisations other >>than
the form originator.

>>Such an inter-organisational infrastructure is only viable if every
>>one adopts the same underlying forms technology. 


E.g. A form will be authored by company X, and perhaps deployed by them on
one or two of their own channels. The form will also be deployed by three
third parties for use by potentially thousands of end users, some of whom
work in organisation with a sophisticated IT infrastructure, while others
have a telephone and fax machine. The form cannot be reauthored in any way.

Um .... not being facetious ... but how do you get the XML instance data
down the phone line or in the fax? It seems to me that some form (forgive
the pun) of refactoring is going on anyway. So, in principle, why not
InfoPath too?

Key points are:

1) The form author does not know how the form is to be deployed at authoring
2) Many organisations will host the same form, providing access to end users
with many different delivery requirments.

Ah ... but what is a "form"? It's a serious question. One the XForms WG
ducked ... shame on them! :) ... and leaves terminology in a flakey state.

If you have a set of form controls on an electronic XForms form and have a
set of similar looking (but non-functioning) widgets on a paper form is that
the "same form"? Or not? It isn't obvious to me. Is the paper form an XForms

I must make a point of seeing how T V Raman handles the issue of "what is a
form?" in his book as I continue reading it. I guess the overview format
allows avoidance of practical little issues like that. "Form" doesn't make
it in the index.

It turned out to be cheaper and more practical to produce our own forms
markup language than to leave all form generators and users to do their own
>>XForms is only an option because it is an open standard, InfoPath, 
>>and other competing forms technologies, are not because they are
>>proprietary. It really is that simple. 

>Are you sure?


I am not convinced yet. :)

>Just curious, but how is a server to tell the difference between an 
>XML instance document submitted by InfoPath and one submitted from an
>XForms client?

For us XForms addresses forms/business rules deployment across organisations
that have contractually regulated relationships. 

OK. But that doesn't answer my question.

>I haven't seen the Adobe XML/PDF technology yet but if it submits an
>identical XML instance document why should that automatically fail to >meet
your needs?

Hopefully that should be clear from comments above.

No. It isn't clear to me.

>Does your industry's application require that the visible "form" of 
>the form is common? Or that the XML data submitted is?

Both or either depending on circumstances. 

So if InfoPath could submit identical to XForms that would be ok in some

Then there is the matter of the business rules underlying a form.

What do you mean by business rules in this context?

I am challenging your proposition of this type of decision being simple and
the assertion that "standards" are "all there is to it". I simply am not
convinced that it is "that simple".

The assessment of your needs is yours and the decision on a chosen solution
likewise. I do find it difficult to see how this is as simple as you

Andrew Watt 

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

Received on Friday, 10 October 2003 07:53:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:09 UTC