- From: <AndrewWatt2001@aol.com>
- Date: Fri, 10 Oct 2003 06:14:04 EDT
- To: MSeaborne@origoservices.com
- Cc: www-forms@w3.org, XForms@yahoogroups.com
- Message-ID: <2b.4934f5b1.2cb7e06c@aol.com>
In a message dated 10/10/2003 10:18:49 GMT Daylight Time, MSeaborne@origoservices.com writes: Hi Mark, Long time no see. :) > 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. As I mentioned in other posts applications which require wide and unpredictable forms deployment and completion are not well suited to InfoPath 2003. Such an inter-organisational infrastructure is only viable if every one adopts the same > underlying forms technology. Why? We are not in a situation where everyone is happy to buy the same proprietary solution > from one vendor, so the only option is to go with an open (ie not owned by > one implementer) standard implemented by a range of vendors. In the absence > of XForms, we came up with our own standard. Now that XForms is viable > alternative we will start moving to that. > > 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? 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? 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? Does your industry's application require that the visible "form" of the form is common? Or that the XML data submitted is? 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? The Industry requires a high level of interoperability without many hundreds of companies > of all shapes and sizes all having to buy from the same vendor. Clearly if > XForms is not implemented interoperably then it will fail. However, I think > those who are starting to bring XForms products to market have grasped the > fundamental value of the technology as an open standard, and I am confident > that lack of interoperability will not be a big problem. > > Getting back to the browser issue; there is clearly a need to deliver XForms > to the client via a web browser. If the browser implementers do not meet > this need themselves, then others will, and indeed have already been doing so > for some time. > Browser delivery meets the needs of scenarios which InfoPath 2003 doesn't address. No argument there. Andrew Watt
Received on Friday, 10 October 2003 06:14:09 UTC