لطفا منتظر باشید ...
XML Forms
Consider first the very general example of the expense or travel claim. Suppose Human Resources has given you an electronic copy of an Excel sheet that will work everything out for you. You fill in the blanks and print it out. Then you put it on your manager’s desk so she can sign it. Eventually, it gets to Payroll, where someone else enters some or all of the data again.Now you perform the same task, this time using InfoPath. Instead of a spreadsheet, you download a form template to complete. It also does the necessary calculations. You e-mail it to your manager, who approves it with a digital signature and routes the form to anyone else who needs to sign. The XML data is harvested by the payroll system, and the repayment gets added to your pay slip in time for the big weekend you have planned. This by itself is probably a sufficient motive for any developer to learn InfoPath and implement a new staff expenses system.From a less selfish perspective, think of the thoroughly forms-intensive business processes where data is still bound up in paper-based systems. If you have ever worked for an insurance company, a financial services firm, a hospital, or a government department, you’ll see the huge potential in unlocking the data carried in office forms.But without a doubt the most attractive feature of InfoPath is that you can hide the complexities of XML from end users. Even if you understand XML, it can get in the way. A while ago, one of us explored the idea of introducing XML capture for a large group of developers working on a complex API. It would have made the creation of an HTML reference easy, but while everyone saw the validity of the business case, they rebelled at the thought of using a traditional XML editor. If InfoPath had been available then, no doubt they would have been more supportive.Microsoft isn’t the first, let alone the only, vendor to spot the opportunity for forms tools, and there will be plenty of competition for this very large market segment. Microsoft may have an advantage, however, because of its dominant position in the office market.To put InfoPath in context, we suggest you take a few moments to look at the alternatives there are to the approach that Microsoft has taken. Several observers and commentators have compared InfoPath to XForms, a recent W3C Draft Recommendation intended to be integrated into other markup languages, such as XHTML or SVG. See, for example, Michael Dubinko’s XForms and Microsoft InfoPath at [www.xml.com/pub/a/2003/10/29/infopathl.]
Perhaps the comparison is made because there is an implied expectation that forms processing should mainly follow the Web processing model. You may or may not agree that the Web is the natural home for forms, but in any case a direct comparison just isn’t productive. As Dubinko points out, that’s because InfoPath is an application, whereas XForms, together with a number of other interface markup languages, is an XML vocabulary.It may be more helpful to look at points of similarity and difference adopted by developers of XML forms applications, including XForms.
Common Features in XML Forms
When it comes down to it, XML forms processors have more in common than you might think. Essentially, they are there to convert user input into new or modified XML data, which can then be routed through a series of business process, possibly on multiple platforms in different organizations.
A central design concept is a “package” of files with distinct functions: a template document with a structure definition from a fixed, industry-standard or custom XML schema; an XML file to contain default data; and form data in an XML file that can be routed to points in a workflow. At each point, the data is loaded into a form, which provides a view into editing all or parts of the form. This process can be repeated as many times as necessary, with any number of participants.Some approaches, like XForms, use fixed element names for controls and encourage implementers to define the purpose of the data-gathering controls. This makes it easier to generate the related structures automatically, for example, creating different interface objects for PDA and desktop browsers. Others are more focused on providing a rich user interface (UI). However, most have a wide range of display properties that include showing or hiding parts of forms and repeating sections where elements can be added or removed by users.
Points of Difference
Probably the first distinction to note is between Web-based XML forms and rich client systems. Web-based applications have their attractions, and on office intranets they have become a common way to collect some kinds of information from employees. They are easy to deploy and inexpensive to support. But thus far they have not been good candidates for workflow processing. That will soon change as XForms-based tools appear.Rich client applications are relatively expensive to deploy and maintain, but they are often more robust and can be more readily integrated with other desktop client systems. They can be operated when users are disconnected from the network, and there is some evidence that users prefer them to Web-based tools when they have a choice.Another distinction is between declarative and scripting approaches. A goal of the XForms specification was to limit the need for scripting; it therefore makes use of XPath-based calculation and validation, and includes XML action elements that specify responses to events like setting focus or changing a data value. In contrast, InfoPath, although it makes some use of declarative programming, including XPath expressions, encourages the use of script more often.
