Browse Prior Art Database

Algorithm for user interface construction based on DTDs

IP.com Disclosure Number: IPCOM000013315D
Original Publication Date: 2001-Jun-03
Included in the Prior Art Database: 2003-Jun-18
Document File: 4 page(s) / 168K

Publishing Venue

IBM

Abstract

Automated interface creation from DTDs One of the biggest challenges of any publishing system is to remove as much complexity from the users’ tasks as possible. When dealing with a relatively new technology like XML/XSL this aspect of the system becomes even more important. By hiding the syntax of XML from the editors and authors, domain experts can take on the role of creating and modifying the content without worrying about the syntax of a particular markup language. One goal of Franklin, therefore, is to never present the tagging syntax to the user. Instead, Franklin creates a set of input forms that the user can easily fill out. However, some users insisted on placing simple HTML markup into text fields. Franklin does allow a small subset of HTML tags to be processed. However, this defeats many of the reusability and cross-platform publishing opportunities and is not a recommended strategy. Users are assigned roles in the system and each role, in turn, is assigned specific document types. A user assigned to a role can only create or modify a document assigned to that role. When the user selects a document type to create or edit, Franklin reads in the DTD and automatically constructs an interface based on that document structure.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 4

Algorithm for user interface construction based on DTDs

Automated interface creation from DTDs

One of the biggest challenges of any publishing system is to remove as much complexity from the users' tasks as possible. When dealing with a relatively new technology like XML/XSL this aspect of the system becomes even more important. By hiding the syntax of XML from the editors and authors, domain experts can take on the role of creating and modifying the content without worrying about the syntax of a particular markup language.

One goal of Franklin, therefore, is to never present the tagging syntax to the user. Instead, Franklin creates a set of input forms that the user can easily fill out. However, some users insisted on placing simple HTML markup into text fields. Franklin does allow a small subset of HTML tags to be processed. However, this defeats many of the reusability and cross-platform publishing opportunities and is not a recommended strategy.

Users are assigned roles in the system and each role, in turn, is assigned specific document types. A user assigned to a role can only create or modify a document assigned to that role. When the user selects a document type to create or edit, Franklin reads in the DTD and automatically constructs an interface based on that document structure.

DTD to Interface

The UI creation algorithm first constructs the basic interface from the DTD. This recursively adds widgets to the display as necessary. If we are creating a new document we simply display the widgets. If we are creating an interface from an existing XML instance, however, we insert the content into the appropriate widget. In addition, we must create additional widgets for elements that are repeated within the XML document.

Franklin makes a number of assumptions in handling DTDs and the automatic creation of the user interface. Most notably, the interface widgets are created for DTD elements, not attributes. Special attributes are then used to assist in the transformation of the element into an appropriate interface widget.

Until schemas become widely used, there is no standard way to provide typing for elements in the DTD. Franklin solves this problem by including the attribute, DATATYPE, whenever an element is to be displayed in the interface. If an element does not contain a DATATYPE attribute no input is allowed for that element. Children elements, however, may still contain DATATYPE attributes to specify their user interface. In addition, whenever an element has the DATATYPE attribute, it must contain a child of type PCDATA. This enables the DTD to specify, for example, whether a one line input, a medium text area or a large text area is required.

In the partial DTD shown here, TITLE, SHORTDESCRIPTION, and BODY each specify different text input widgets to use.

<!ELEMENT TITLE (#PCDATA)>

<!ELEMENT SHORTDESCRIPTION (#PCDATA)>

<!ELEMENT BODY (#PCDATA)>

1

Page 2 of 4

  <!ATTLIST TITLE DATATYPE (%UITYPES;) "STRING"
#FIXED>

  <!ATTLIST S...