Forms are a part of our lives. They are used day by day in the ordinary life, but online they have a special place. They are the primary way of collecting information, being used for search engines, polls, surveys, electronic commerce, and even on-line applications. Every type of user-interaction on-line is done through web-forms of some sort. However, this technology is already showing it's age. Being created 5 years before XML, it has limitations, that make developer's and user's lives harder. Among them are:
As forms are older than XML,
Forms are for collecting data, so it's not surprising that the most important concept in XForms is "instance data", an internal representation of the data mapped to the familiar "form controls". Instance data is based on XML and defined in terms of XPath's internal tree representation and processing of XML.
It might seem strange at first to associate XPath and XForms. XPath is best known as the common layer between XSLT and XPointer, not as a foundation for web forms. As XForms evolved, however, it became apparent that forms needed greater structure
Abstract
This document is a liaison statement from XML Linking Working Group to the XML Information Set working group. Because the XPointer specification under development in the XML Linking WG must refer to structural parts of XML documents, the structure it addresses must be explicit. Document structure specifications such as DOM and the XML Information Set may wish to consider the XPointer requirements in order to insure interoperability when used with XPointer and XLink. Thus we have set out in this document, some constraints we believe XPointer
RSS/XML