Wiki Form Requirements
Advisor/Customer: Martin Bravenboer
and Eelco Visser
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
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
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.
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.
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 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.
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
- Develop an alternative implementation for browsers that do not support XForms. The form definitions in GW should remain the same.
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
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.
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)