Wiki Form Requirements

Advisor/Customer: Martin Bravenboer and Eelco Visser

Introduction

Wiki webs are used to maintain and develop a web of information with a group of people. In current Wiki implementations this information is restricted to text documents. The text documents are written in a simple markup language and are presented in a browser. The goal of the Forms project is to experiment with collaborative maintenance of structured information. This information could be structured in XML, but it could also be stored in ad-hoc notations that are part of the text documents. Examples of this are the WebNotify, Preferences, and Category feature of TWiki.

Structured information can be edited at the source level, i.e. an XML document could simply be edited as an ordinary plain text file, but this will not make the web application accessible to users that are not deeply involved in the structure of the web application. This approach would be comparable to diving into a relational database and executing SQL queries and update.

To make the manipulation of structured data more user-friendly, we need to be able to attach forms to edit topics. These forms are an alternative to editing the structured source of a Wiki topic. The ultimate goal is to have

If GW Forms are to be compared with the Model View Controller pattern, then the most striking difference is that GW Forms will probably not have a controller: GW Forms are restricted to editing the structured of a single file and will not be used to implement web applications with complex control flow.

This project will have a more experimental nature than the other project. Hence, the requirements are not very specific and might be changed, based on the experiences of the team working on the Forms project. If one of the approaches appears to be particularly useful, then it might be used for the development of an entire web application.

Overview

A GW Form should do several things:

• Describe the structure and presentation of a form.
• Create an instance of a form, based on existing data.
• Map the changes performed by the user back to the data.
• Verify that the data is correct and send feedback if it is not.

We will mostly focus on data stored as XML documents.

Server-side Validation

The first step towards structured information in a Wiki is to ensure that the information stays structured. For information stored in XML this means that the Wiki files should remain well-formed and valid.

More concrete requirements are:

• Verify the well-formedness of XML documents, or rather, files that are supposed to be XML documents.

• Verify the well-formedness of XML documents with a schema or multiple schemas. Schema languages that should be supported: Schematron, RELAX NG, W3C? XML Schema.

• Arbitrary validators implemented in a scripting language (Groovy or Jython).

• Arbitrary validors implemented in Java.

The validators that are to be applied must be defined in meta files.

Some form techniques that we will experiment with in this project also allow client-side validation. This is only suitable for improving the user experience, since a client cannot be trusted.

HTML Forms

The only advantage of HTML Forms is that they are available in every browser. However, they are not suitable for developing Forms without any scripting or other server-side code. Still, it is in practice the only option for creating web forms.

• Develop a method for defining GW Forms as HTML Forms. Use server-side code that can be edited online to bind the form to the structured data of a GW file. The server-side code might for example be written in Java, Groovy, etc.

Client-side XForms

Client-side XForms improve the user experience by allowing client-side validation, offering more widgets, etc. Although most browsers do currently not support XForms, this is probably the future of forms in web applications. Mozilla will include XForms in future builds and plugins are available for Internet Explorer. XForm client-side and server-side libraries exist for platforms like Java.

• Develop a method for defining XForms to edit the XML data of GW files.

Server-side XForms

The lack of browser support for XForms is a serious problem in any website that is going to be used in practice. This could be solved by using server-side XForm libraries, or client-side plugins (maybe Java).

• Develop an alternative implementation for browsers that do not support XForms. The form definitions in GW should remain the same.

XUL Forms

XUL is the user-interface technique used by the Mozilla platform. The ultimate goal of XUL is to provide a platform for the development of platform independent independent graphical user interface applications. Most applications rely heavily in JavaScript? , which makes the Form less declarative. Another limitation is that XUL-based web applications will probably only work in Mozilla browsers: there are currently no efforts to make XUL a true web standard.

• Develop examples of XUL based web applications that are hosted and maintained in a Wiki.

Use Cases

Some application that can be used to test the various approaches are:

• GW Configuration (variables)
• User preferences
• List of users in web notification service
• Category editing
• Form for BibTex? entry editing

Full web applications:

• Conference management (paper sumbission)