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

But not all enterprises are the same.  Pardon me if I am misinterpreting
what you are saying, but as I mentioned in my last post, you do have
enterprises where the desktop envionment is heterogeneous, i.e., Windows and
some flavour of UNIX (or Linux).  Here, I am talking about the user
community within the enterprise/corporation, not a product that the
enterprise produces for customers outside the enterprise.

With InfoPath (as I understand it), you are limited to Windows IE, leaving
other browsers in the dust.  In the aforementioned environment, one cannot
ignore the browsers that are established corporate standard on the
non-Windows desktops (Netscape/Mozilla comes to mind).  If I am developing a
forms-based interface and application that must be used throughout the
enterprise (i.e. a business req't), then we simply cannot move everyone to a
single platform, or to a single browser.  Not a solution.  Too simplistic.
Too costly.  

It seems that the effectiveness of open standards is proportional to their
level of adoption in the industry.  Failure to support a standard by a major
vendor in the IT industry just throws a monkey-wrench into the endeavour to
develop a cross-platform application.

--john

> -----Original Message-----
> From: Karandikar, Shailesh [mailto:Shailesh.Karandikar@dendrite.com]
> Sent: Friday, October 10, 2003 7:55 AM
> To: AndrewWatt2001@aol.com
> Cc: www-forms@w3.org
> Subject: RE: [XForms] Re: Will Internet Explorer support XForms
> 
> 
> 
> Andrew,
>  
> 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.
>  
> 
> Regards, 
> 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
> 
> 
> Mark,
> 
> 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:
> 
> 
> 
> Andrew,
> 
> >>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. 
> 
> >Why?
> 
> 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
> time
> 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
> form?
> 
> 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
> thing.
>   
> >>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?
> 
> Yes.
> 
> 
> 
> 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
> circumstances?
> 
> 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
> indicate.
> 
> 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 08:42:54 UTC