The newly formed XForms Working group [CFP] wishes to congratulate you on the publication of two significant Last Call Working Drafts: XML Schema Part 1: Structures [Schema-1] and XML Schema Part 2: Datatypes [Schema-2], providing a vast improvement over current DTD-based methods of describing and validating XML.
The XML Schema activity is of great interest to the XForms group. We believe that the "full potential of the Web" would be well served by the universal adoption of a single XML data model description mechanism. However, we have not been able to achieve consensus around adopting XML Schema as-is as the foundation of XForms.
We acknowledge that the issues involved in integrating these two technologies are complex, and finding a mutually acceptable solution will require significant coordination on the parts of both of our groups. As a starting point for a discussion, this document will describe some of the goals and non-goals of the XForms group, particularly where they relate to Schema:
The XForms architecture draws a connection between the XForms data model, representing the data structure of a form, and the XML "instance data", representing the data within the form. However, it is not intended for people to use an XForms data model as a tool to define and validate arbitrary XML--a task we feel is best accomplished using XML Schema.
The design of XForms emphasizes human-computer interactions. Forms are a primary means of interaction on the Web today, and in the majority of cases, a Web form transaction directly involves a person. This continues to be our vision of how XForms will fit into the Web. The XForms Requirements document states, under the heading 1.1 "Rationale":
The design of XForms focuses on the increasing demands for improved human-computer interaction...
Addressing any mutual concerns regarding target audiences will ensure that our work as a team meets our common goals.
One of the key indicators of our group's success will be seeing existing HTML and XHTML forms being migrated to XForms. The XForms Requirements document [XForms-Req] states, in section 2.2:
XForms should be designed in such a way as to encourage users to make use of the new capabilities, rather than lingering on existing form technologies.
We place high value on the existing knowledge base of HTML vendors, programmers, designers, and graphic artists. Indeed, XForms hopes to leverage this knowledge base by offering this constituency access to higher-order functionality through access to XML facilities.
Today's web authors are accustomed to rather basic forms markup, such as <input
type="text"/>. The forms group considers this simplicity
one of the major factors in the success of HTML; we do not have consensus that
the syntax of XML Schema will meet the simplicity expectations of HTML authors.
One manifestation of this is a difference in the defining facets that apply to various datatypes. For instance, the XForms Data Model doesn't define separate 'minInclusive' and 'minExclusive' facets, since we feel that HTML authors are not likely to appreciate the subtle distinction between the two. There are differences that apply both ways--Schema defines some facets that are not present in XForms, and vice versa. A separate document is being prepared with a discussion on these differences is great detail.
The Working Draft of the Platform for Privacy Preferences [P3P] has expressed similar concerns; the XForms group would like to make sure P3P is invited to join in the coordination effort.
We consider another key success indicator will be seeing XForms widely deployed in the crop of new computing devices now becoming available. Many of these devices have extremely limited processing and memory capabilities--so much so that the XForms group has received comments from embedded device and mobile device vendors that an XSchema implementation is unlikely to make it into their devices. The XForms Requirements Document [XForms-Req], continuing in section 2.2, states:
Likewise, the design should encourage implementors to deploy user agents that implement XForms
The XForms group feels, at this time, that unconditionally founding XForms on XML Schema would prevent many useful applications of XForms on small devices. The device vendors themselves have suggested that XSchema compatibility be sorted out via compliance levels or perhaps transformations.
One particular area of concern is the requirement of implementing regular expressions. It is our understanding that, at one point, the Schema group had included a simpler "mask" functionality. The XForms group would like to see some kind of basic mask functionality, along the lines of section 4.1 in the first XForms Data Model Working Draft [XForms-DM]. This would, for instance, allow (perhaps with a mechanism to remove a facet) the definition of a conformance level that would not require a regular expression implementation.
Another specific area of concern is the representation of numbers. We find decimal arithmetic to be well suited to forms, especially in the hands of non-programmers. (Appendix C of our Working Draft [XForms-DM] lists many additional reasons why we find decimal arithmetic appealing.) We would like to work out some technical means to align the concerns of both of our groups in this regard.
As mentioned before, we believe the P3P Working group shares many of these concerns, and would like to seek their input into the coordination process.
XForms is aimed at a broad constituency, as described in section 1.2 of the requirements document [XForms-Req]. The top two audiences are:
By simultaneously addressing client and server-side authors, a major shortcoming of today's Web forms can be overcome. Typically, authors today need to implement their validations twice--once in a client-side scripting language, and again on the server, usually in a different language such as Perl or Java Servlets. XForms are a powerful tool that can be used alike on both client and server. As a consequence of this, XForms occasionally requires functionality not covered by XML Schema.
The XForms group is working on identifying features that are required by XForms but not present in XML Schema. The Schema Requirements Document [Schema-Req] states:
For applications which require other, arbitrary or complicated constraints, the application must perform its own additional validations
While it is certainly possible for XForms to provide an independent set of validations, the XForms group feels that it would be advantageous to work with the Schema group and others to develop a set of enhancements to XML Schema to support directly the validation and other features described in the XForms Data Model [XForms-DM] and [P3P]. We expect to see this deployed both on clients of all sizes and servers.
In particular, we would appreciate the following features in XML Schema:
binary. It would be desirable to have a mechanism
to formally define new facets.The XForms group feels that there is great merit in relating the work of XML Schema, XForms, and P3P in a manner that gains consensus across all three groups. Ideally, this would at some point encompass the entire W3C, where all groups that need a data model could make use of a common core technology. This might include other W3C efforts such as RDF, DOM, XML-Query, and Infoset.
We are currently preparing a document that attempts to list in detail the differences between the XForms Data Model and XML Schema, which we plan on delivering by 25 May 2000. We would appreciate it if some time during the upcoming Edinburgh Schema face-to-face on 1 & 2 June 2000 could be devoted to considering these issues and possible ways to overcome them.
One possible outcome might be the formation of a short-term "Core Data Model Task Force", where a small number of representatives from various groups work together intensely to discuss strategies whereby the technologies can be aligned. The goal of this task force would be to come up with a common data model or a set of complementary models that could be deployed for the customers of each standard, yet retain uniformity across the W3C. The XForms group is willing to commit resources to this effort.
To summarize, this document notes possible differences in the target audiences of XForms and Schema, and calls out the following areas where greater integration between XML Schema, XForms, and P3P can be pursued:
We would like to see the formation of a "Core Data Model Task Force", to forge a mutual understanding of the requirements of the XSchema, XForms, and P3P groups, with particular emphasis on the syntax complexity issue. We would like to work together to build a core data model, or set of complimentary data models that can be deployed across the W3C.
[CFP] Call for Participation: XForms Working group
http://lists.w3.org/Archives/Member/w3c-ac-members/2000AprJun/0018.html
[Schema-Req] XML Schema Requirements
http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215
[Schema-1] XML Schema Part 1: Structures
http://www.w3.org/TR/2000/WD-xmlschema-1-20000407
[Schema-2] XML Schema Part 2: Datatypes
http://www.w3.org/TR/2000/WD-xmlschema-2-20000407
[XForms-Req] XForms Requirements
http://www.w3.org/TR/2000/WD-xhtml-forms-req-20000329
[XForms-DM] XForms 1.0: Data Model
http://www.w3.org/TR/2000/WD-xforms-datamodel-20000406
[P3P] The Platform for Privacy Preferences 1.0
http://www.w3.org/TR/2000/WD-P3P-20000510