This release of DASH revision 3 data entry introduces DASH XML (Extensible Markup Language) form definition. The data entry server now runs the XML forms as well as revision 2 forms as it did in an earlier release.

The following features are new to revision 3 and have no parallel in revision 2.

The DASH revision 3 native form language is XML (eXtensible Markup Language). This is an HTML like language with tags marking the components of the form. Because XML is stored as a text file it can be operated on by editors and any other tool that can deal with text. The choice of XML follows our current goal of making DASH more open and accessible to other software that can work in parallel with DASH.

DASH table variables are defined and included in the XML form. In revision 3 there is no separate variable library. Tabulation variables are made up of question text, answer categories and data field locations which are defined in the form. Since a markup language identifies components uniquely most of the material for tabulations is easily identifiable. The artificial separation of entry forms and variable definitions creates an enormous amount of extra labour. Also since all variable definitions are now plain text automated processing by other tools is straightforward.

The command language of DASH revision 3 is all Tcl. All form fields may be accessed directly from within the Tcl code to allow superior functionality to DASH revision 2. DASH revision 2 commands will be emulated with Tcl procedures but everyone will be required to learn at least a little Tcl syntax.

The command language for specifying conditions for table counts is also Tcl. This increases the functionality possible in table computations greatly. Using Tcl, unlimited compexity can be incorporated by using "expr" and external procedures for complex calculations.

All pages and fields in rev 3 are assigned arbitrary names as unique identifiers. There is no page or field numbering. The DASH rev 2 to XML form converter will assign "p#" to each page identifier and "p#f#" to each field identifier. However the field named "p6f1" may be moved to "p37" without any effect on storage or form operation. Any reference to "p6f1" from anywhere in the form will locate the correct field. Of course a new form might assign meaningful names to fields such as "age", "sex", "language" etc. This means that a demographic section anywhere in a form could be tabulated with the same default variables in all forms once they were defined.

New pages may be added anywhere in the form with any number of fields on the page with no effect on storage of the existing data.

Fields may be added anywhere on an existing page since storage is determined by field name and not by its location. Fields may be shortened or lengthened in the form after entry to the case file with no effect on storage of the data.

Text entry to all fields of length 5 or greater is unlimited and will scroll as necessary. Fields of length less than 5 terminate input automatically at the end of the field as in DASH revision 2. The choice of 5 is arbitrary and may be modified in the future. This feature is for convenience in entering small fields with textual data.

New fields alias, button, check, image, integer, list, radio, scale, text, and tree are added to the current rev 2 list of DASH field types. Most of the new fields are convenient for mouse access only although they can be manipulated via the keyboard. Fields may also now have a "use" attribute which gives them a special status in the software. Instead of a command specifying a field as a timezone field, in rev 3 the field will have a "use=timezone" attribute.

In rev 3 lists take on an entirely new function to serve multiple purposes. The list is defined to be made up of (value, label) pairs and is used for both specifying complex field display options and also for field display content. A field such as a check field has an option list and a display list. The option list may be empty which would create a default check field presentation. If the option list is assigned values for items such as "orient=vertical", "columns=6", "height=4" etc., then the display of the check field would be governed by these attributes. The display list specifies the "label" to be displayed for each check-box and the "value" that is stored in the data file if the item is selected by the user. The lists are independent of the field and are assigned to the field as an attribute with a list identifier. Hence the same list can be reused to specify field options for the same type of field through the entire form. Also the same display list can be easily assigned to a tabulation variable eliminating any duplication.

Commands in forms are marked up to be executed in several new categories such as "preform", "postform", "precase" and "postcase" as well as the current "pre" and "post" which could have been called "prepage" and "postpage". Current field commands are marked up within a field definition and hence have no dependence on field reference as they do in revision 2.

Form commands have 2 components as they do in revision 2 of DASH. Each command has a "do" component which is executed if the "if" component evaluates to true. The radical difference occurs because the "if" component may be any Tcl code or procedure as long as it returns 1 or 0 to indicate success or failure. This means that you may execute logic such as,

      do_something if (p2f1 + p2f2*75) > 10
    

The above command is in DASH rev 2 syntax to allow an appreciation of the increased functionality, particularly in tables.

Some of the new fields like "check" and "list" with a multiple selection option create multiple answers for a field. DASH rev3 file structure accomodates multi-valued fields to any depth. In addition the "Special Input" entry, now known as "Note" will also be stored in the field as well as any regular data that is entered to the field. Hence all DASH fields can be multi-valued if a Note is entered to a field. The data may be entered before or after the Note.

Any number of language forms may work concurrently and are selected from a list of languages. The language is specified in the form "language" attribute. Because unicode is used for text storage, most of the world languages may be accomodated as long as the client display device contains an appropriate font to display the form and data. The files must be named formname.r0, formname.r1, formname.r2 etc. for revision 2 forms and formname.x0, formname.x1 etc for revision 3 XML forms. Each alternate form may have additional page/field layouts or even mutually exclusive layouts since data is stored by field name and can be anywhere.

A large number of cases may be stored in the file structure. The software supports 64 bit indexing and data files as large as the underlying operating system can support.