US20070100877A1 - Building Electronic Forms - Google Patents

Abstract

A system and method that enables a designer to build electronic forms and corresponding hierarchical schemas are described. Displays of hierarchical schemas, electronic forms, and components used to build the hierarchical schemas and electronic forms are provided to the designer. The designer selects components and arranges them on a display to visually build an electronic form. As the form is built, the corresponding hierarchical schema is incrementally updated to reflect changes made to the electronic form.

Description

RELATED APPLICATIONS
• This application is a divisional of and claims priority to U.S. patent application Ser. No. 10/395,505, filed Mar. 24, 2003, the disclosure of which is incorporated by reference herein.
TECHNICAL FIELD
• This invention relates to designing electronic forms and hierarchical schemas, and more particularly, to a user-friendly way to incrementally design electronic forms and hierarchical schemas.
BACKGROUND
• Extensible markup language (XML) is increasingly becoming the preferred format for transferring information. XML is a tag-based hierarchical language that is extremely rich in terms of the information that it can be used to represent. For example, XML can be used to represent information spanning the spectrum from semi-structured information (such as one would find in a word processing document) to generally structured information (such as that which is contained in a table). XML is well-suited for many types of communication including business-to-business and client-to-server communication. For more information on XML, XSLT, and XML Schema, the reader is referred to the following documents which are the work of, and available from the W3C (World Wide Web consortium): XML 1.0 second edition specification; XSL Transformations (XSLT) Version 1.0; XML Schema Part 1: Structures; and XML Schema Part 2: Datatypes.
• Before information can be transferred, however, it must first be collected. Electronic forms are commonly used to collect information. One way to collect information and have it also in an XML document is to have the electronic form correspond to an XML schema. By so doing, the information entered into an electronic form can be stored in an XML document, which conforms to the XML schema. Having information within an XML document that conforms to an XML schema allows the XML document to be understood and validated when transferred to others having access to the XML schema.
• Currently, to begin creating an electronic form corresponding to an XML schema, a skilled programmer can write an XML schema and then, once the XML schema is written, abstract how information conforming to that schema will be entered. With the abstraction of how the information will be entered, the programmer can then create an electronic form that maps data-entry fields to that schema. The programmer can map data-entry fields to that schema using an XML path language (XPath), such as the W3C-standard XML path language (information about which is currently available from W3C at www.w3.org/TR/xpath). This process of creating an electronic form, however, is time consuming and can require a programmer of significant skill.
• To create these electronic forms, the programmer often needs a significant understanding of HTML and XML Schemas. The programmer, to build an electronic form with even moderately complex data-entry fields—such as repeating data-entry fields—often needs to understand how these data-entry fields are represented in the schema, HTML file, and XML data file. Also, to build a relatively simple electronic form with simple data-entry fields the programmer often needs to understand how HTML, XML, and XML Schemas are structured and how they are interrelated. Thus, to build one of these electronic forms, a programmer often must have significant experience and skill.
• For these reasons, creating electronic forms and corresponding schemas can be difficult, time consuming, and require a programmer of significant skill.
SUMMARY
• In the following description and figures, a design application enabling a designer to incrementally build an electronic form and corresponding hierarchical schema is disclosed. This design application can also enable a designer to change an electronic form or corresponding hierarchical schema and simultaneously view the change in the electronic form and/or corresponding hierarchical schema.
• In one implementation, the design application enables a designer to build an electronic form and corresponding hierarchical schema by incrementally building the electronic form and corresponding hierarchical schema using components.
• In another implementation, the design application enables a designer to set the hierarchical nature of a hierarchical schema by the designer placing components in certain areas of a screen.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates a system with a display screen, computer, and user-input devices. The system implements a method for designing electronic forms.
• FIG. 2 illustrates an exemplary screen display showing a hierarchical schema display area and an electronic form in the form-design area being designed with a method for designing electronic forms.
• FIG. 3 illustrates an exemplary component display area.
• FIG. 4 is a flow diagram of an exemplary process for generating electronic forms and hierarchical schemas.
• FIG. 5 illustrates an exemplary screen display showing a component display area and a blank form-design area.
• FIG. 6 illustrates an exemplary screen display showing part of a hierarchical schema display area, a component display area, and a form-design area.
• FIG. 7 illustrates an exemplary screen display showing part of a hierarchical schema display area, a component display area, and a form-design area.
• FIG. 8 illustrates an exemplary screen display showing a hierarchical schema display area and a form-design area.
• FIG. 9 illustrates an exemplary screen display showing a hierarchical schema display area, a form-design area, a component context menu, and a structure submenu.
• FIG. 10 illustrates an exemplary hierarchical schema display area, a change inquiry window, and an add window.
• FIG. 11 is a flow diagram of an exemplary process for building a hierarchical schema.
• FIG. 12 illustrates an exemplary screen display showing a hierarchical schema display area and a form-design area.
• FIG. 13 is a block diagram of a computer system that is capable of supporting an electronic-form and hierarchical-schema generation process.
• The same numbers are used throughout the disclosure and figures to reference like components and features.
DETAILED DESCRIPTION
• The following disclosure describes a user-friendly way to design electronic forms and corresponding hierarchical schemas using components and a form-designing area of a display. Components are presented in an area of a display screen, usually graphically, such as with an arrangement of icons. Icons representing each component are a simplification so that a designer can more easily understand the purpose of and choose from a list of components. A designer can choose each component that he or she wishes to include in an electronic form.
• The designer can choose a component, such as by clicking on an icon representing a component, to be placed on a form-designing area. The form-designing area is presented in an area of a display screen, usually appearing as a blank page, such as is often done when viewing a new document in a word-processing application. Components placed in a form-designing area can be manipulated by a designer to allow the designer to make an electronic form look and feel like the designer desires. Parts of a hierarchical schema, called schema parts, correspond to the components in the form-design area, and can also be manipulated by the designer. This hierarchical schema can be represented as an XML file or as a data store. When represented as an XML file, a data store can also later be inferred from it.
• With each new component added or modified, and in some cases each change made to an electronic form or hierarchical schema, the electronic form and corresponding hierarchical schema are altered to reflect that change. This incremental building of an electronic form and hierarchical schema, and the fact that they are linked so that a change to one can almost instantly be reflected in the other, allows a designer to quickly, easily, and intuitively create electronic forms and corresponding hierarchical schemas.
• For discussion purposes, the visual representation of the components, hierarchical schema, and electronic form are described in the context of a single computer, a set of user-input devices, and a single display screen having areas for displaying a representation of the components, the electronic form, and the hierarchical schema. The display screen, computer, and user-input devices will be described first, followed by a discussion of the techniques in which these and other devices can be used.
• System Architecture
• FIG. 1 shows an exemplary implementation of various devices and an application that can be used to facilitate the creation of electronic forms from a list of components.
• FIG. 1 shows anexemplary system100, which includes ascreen102, user-input devices104, and acomputer106.
• The user-input devices104 can include any device allowing a computer to receive a designer's preferences, such as akeyboard114, other device(s)116, and amouse118. Theother input devices116 can include a touch screen, a voice-activated input device, a track ball, and any other device that allows thesystem100 to receive input from a designer. Thecomputer106 includes aprocessing unit120 and random access memory and/or read-only memory122 including applications, such as anoperating system124 and a form and adesign application126, which includes auser interface128. Thecomputer106 communicates with a designer through thescreen102 and the user-input devices104.
• Thescreen102 includes three displays or screen areas: a hierarchicalschema display area108; acomponent display area110; and a form-design area112. With these areas, a designer can see a representation of and select a component from a list of components. He can also see a representation of the component in an electronic form and schema parts corresponding to the component in a representation of the hierarchical schema.
• FIG. 2 shows anexemplary design screen200, including an example of the form-design area112 and the hierarchical schema display area108 (entitled “Data Source”). Partially within the form-design area112 is a design view of anelectronic form202. Theelectronic form202 is a design view because it is in the process of being constructed and so can include information for the designer not intended for viewing by a data entry user. Thiselectronic form202 is being built from components chosen by a designer. The components chosen create the data-entry fields shown in theelectronic form202. These data-entry fields correspond to parts of a hierarchical schema, the parts being shown through the icons displayed in the hierarchicalschema display area108. The icons displayed are a representation of part of a file of hierarchical schema arranged into a tree structure.
• FIG. 3 shows an example of components from which a designer can choose, which are displayed here at thecomponent display area110. These various components include atext box302, arich text box304, a drop-downlist box306, alist box308, adate picker310, acheck box312, anoption button314, asection316, anoptional section318, a repeatingsection320, a repeating table322, abulleted list324, a numberedlist326, aplain list328, abutton330, and hyperlink332. Other components can be included as well. As described in further detail below, each of these components represents a data-entry field that can be added to an electronic form.
• With the listed components and other components thesystem100 enables a designer to build a hierarchical schema and an electronic form with many different types of components, allowing for many different possible types of data-entry fields, such as theelectronic form202 in the form-design area112 ofFIG. 2. The process used to build an electronic form and hierarchical schema from components will be set forth in greater detail below.
• The above devices and applications are merely representative, and other known devices and applications may be substituted for or added to those shown inFIG. 1. One example of another known device that can be substituted for those shown inFIG. 1 is the device shown inFIG. 13. Other examples include portable, handheld, or wireless devices.
• Techniques for Building Forms and Hierarchical Schemas
• Overview
• A system, such as thesystem100 ofFIG. 1, displays components to a designer. The designer can choose from the components to graphically and easily build an electronic form and a corresponding hierarchical schema. Thesystem100 can also incrementally build an electronic form and hierarchical schema with each new component the designer adds, which allows the designer to see the electronic form and/or hierarchical schema grow with each new component chosen. The designer may also change components existing in the electronic form, the change to each being incrementally reflected by thesystem100.
• FIG. 4 shows aprocess400 for generating an electronic form and a corresponding hierarchical schema. Theprocess400 is illustrated as a series of blocks representing individual operations or acts performed by thesystem100. Theprocess400 may be implemented in any suitable hardware, software, firmware, or combination thereof. In the case of software and firmware, theprocess400 represents a set of operations implemented as computer-executable instructions stored in thememory122 and executable by theprocessing unit120.
• Displaying Components and Form-Design Area
• Atblock402, theuser interface128 displays components and a form-design area. It does so to enable a designer to graphically design an electronic form.
• FIG. 5 shows adesign screen500 created by theuser interface128, having an example of thecomponent display area110 and a blank example of the form-design area112. The form-design area112 is displayed to make it easy for a designer without typical programming skills to create an electronic form and corresponding hierarchical schema.
• To make it easy, theuser interface128 can provide an editing experience to a designer similar to that commonly provided in word-processing systems. Theuser interface128 can, for instance, work like a word-processing system by providing similar font controls and options. InFIG. 5, for example, theuser interface128 displays the form-design area112 looking like a page from a word-processing application, here a blank, white page. It can also display commonly used icons that represent operations that a designer can choose to perform, such as the font being used (inFIG. 5, Verdana, size 10), bold/underline/italic options, and the like. These word-processing icons can be displayed in many different ways, including as shown in a word-processing icon display502 ofFIG. 5.
• Also, as stated elsewhere herein, changes made by the designer to the form-design area112 can be reflected in the form-design area112 instantaneously (from the perspective of the designer), further making the design process similar to a typical word-processing experience. By so doing, theuser interface128 makes designing an electronic form simpler and more intuitive for a person skilled in word-processing.
• The components are displayed by theuser interface128 in thecomponent display area110 to make it easy for a designer without extensive knowledge of components to be able to understand what each of them can represent in an electronic form. To show what each component represents, theuser interface128 displays icons and/or text to inform the designer, such as with the icons and text set forth in thecomponent display area110 set forth inFIGS. 3 and 5. InFIG. 3, for example, thetext box302 includes an icon (i.e., a symbol) and text describing what a text box component represents. This icon shows a designer that, should he choose to include a text box component in his electronic form, he will have a data-entry field in which a user of the electronic form will be permitted to input text. Likewise, the text describing the text box302 (“Text Box”) is also descriptive.
• With thecomponent display area110 and the form-design area112 displayed, the designer can begin to build an electronic form and corresponding hierarchical schema. He can continue to build the electronic form and hierarchical schema by adding components, but can also alter the electronic form and hierarchical schema by altering existing components. This process of building and altering is shown as adesign sub-process403, which includesblocks404 to412. The sub-process403 includes blocks used to describe the action and interaction of the designer and thesystem100. When the designer has finished with the electronic form and hierarchical schema, thedesign application126 produces the resulting electronic form and hierarchical schema (block414). Theprocess403 and theblock414 will be described in greater detail below.
• When thecomponent display area110 and the form-design area112 are presented, the designer can pick a component from the list of components in thecomponent display area110 for insertion into the form-design area112 (block404). The designer can pick from components in various ways, including through themouse118, the other devices116 (such as a touch screen, track ball, voice-activation, and the like), and through thekeyboard114, which are shown inFIG. 1. To grant flexibility to the designer, thesystem100 enables the designer to move the component in the form-design area112 to where she desires.
• A designer can pick a component, for example, by dragging and dropping (from the component display area110) a component's icon onto a form-design area112 shown inFIG. 5. The designer can pick a component to drag and drop with various devices, such as with themouse118 or commands entered through thekeyboard114. InFIG. 5, the designer clicks on the icon and text for thetext box302 to select it.
• How an icon for a component looks may not exactly indicate how it will look in an electronic form, as icons are too small to be exact. Rather, icons are designed to indicate the look and/or function of the data-entry fields that choosing the component will create.
• FIG. 6 shows anexemplary screen display600 showing what thedesign application126 creates after a designer selects thetext box302 inFIG. 5 (also shown inFIG. 6). In this example, thesystem100 creates a text box data-entry field602, which looks like a gray box for entry of text and is labeled “String 1:”, in response to the designer's selection. Thedesign application126 enables the designer to continue building his electronic form by selecting components, thereby creating data-entry fields.
• Building an Electronic Form and Hierarchical Schema
• Once thesystem100 receives a selection of a component and the placement for the component, thesystem100 can identify which component was selected, identify the placement for that component on the form-design area112, build a hierarchical schema and electronic form based on the component chosen and its location, display the electronic form and/or the hierarchical schema, and, when the designer is finished, produce the resulting electronic form and hierarchical schema. These tasks are set forth inblocks406,408,410, and414 ofFIG. 4, which will be described below.
• Inblock406, thedesign application126 identifies which component was selected. Thesystem100 can access and/or contain many components, either from local or remote sources. Some of these components are set forth (via icons and text) in thecomponent display area110 shown inFIGS. 3, 5,6, and7.
• Also in theblock406, thedesign application126 identifies where a component is placed in the form-design area112. The placement of the component can alter the structure of a corresponding hierarchical schema. How the placement of a component can alter the hierarchical schema's structure will be set forth in greater detail below.
• If, for example, a designer chooses thetext box302 from thecomponent display area110 ofFIG. 5, and places thetext box302 in the upper left corner of the form-design area112, thedesign application126 will identify the component and its placement. In this example, thedesign application126 will identify that the component chosen was thetext box302 and the placement was a particular spot in the upper left corner of the form-design area112. With this information, thesystem100 proceeds to build the electronic form and hierarchical schema, which will be described in part usingFIGS. 5 and 6.
• Inblock408, thedesign application126 changes an electronic form and corresponding hierarchical schema based on a component selected. When a component is added, as has been described in part above, thedesign application126 changes the hierarchical schema and electronic form by building in the added component. When an existing component is altered (discussed in greater detail below), thedesign application126 changes the electronic form and hierarchical schema to reflect that alteration.
• The structure of each component placed into the form-design area112 is reflected in a corresponding hierarchical schema. The structure or code added to the hierarchical schema for each component selected is called a schema part. Each schema part governs the information added (such as by a data-entry user of the electronic form built by the design application126) into each data-entry field in an electronic form that corresponds to the same component for which the schema part corresponds. A check box component's schema part, for instance, allows only the following values: true, false, 0, or 1 (by default).
• Thus, a hierarchical schema governs how information is handled that is input into an electronic form for which it corresponds. Because a hierarchical schema includes the structure of each component chosen, the structure of each chosen component affects the structure of the hierarchical schema. For example, the following components, when added to an electronic form, will add a schema part (when using an XML Schema) having the following code to a hierarchical schema corresponding to the electronic form:

  Component
  name	Schema Part's Code
  Text Box	<element name=”field#” type=”string”/>
  Rich Text Box	<element name=”field#”>
  	<complexType mixed=”true”>
  	<sequence>
  	<any     minOccurs=”0”
  	maxOccurs=”unbounded”
  	namespace=”http://www.w3.org/1999/xhtml”
  	processContents=”lax” />
  	</sequence>
  	</complexType>
  	</element>
  Check Box	<element name=”field#” type=”boolean”/>
  List Box	<element name=”field#” type=”string”/>
  Drop-Down List Box	<element name=”field#” type=”string”/>
  Option Button	<element name=”field#” type=”string”/>
  Date Picker	<element name=”field#” type=”date”/>
  Picture (linked)	<element     name=”field#” type=”anyURI”/>
  Picture (inline)	<element name=”field#”
  	type=”base64Binary”/>
  List (plain, numbered, or	<element name=”group#”>
  bulleted)	<complexType>
  	<sequence>
  	<element name=”field#”
  	type=”string”
  	maxOccurs=”unbounded”/>
  	</sequence>
  	</complexType>
  	</element>
  Section, and Optional	<element name=”group#”>
  Section	<complexType>
  	<!-- EMPTY CONTAINER -->
  	</complexType>
  	</element>
  Repeating Section	<element name=”group#”>
  	<complexType>
  	<sequence>
  	<element name=”group#”
  	maxOccurs=”unbounded”>
  	<complexType>
  	<!-- EMPTY CONTAINER -->
  	</complexType>
  	</element>
  	</sequence>
  	</complexType>
  	</element>
  Repeating Table	<element name=”group#”>
  	<complexType>
  	<element name=”group#”
  	maxOccurs=”unbounded”>
  	<complexType>
  	<sequence>
  	<element name=”field#” type=”string”/>
  	<element name=”field#” type=”string”/>
  	<element name=”field#” type=”string”/>
  	<!-- Etc. for each column   -->
  	</sequence>
  	</complexType>
  	</element>
  	</complexType>
  	</element>
  	Note: The number of columns is used to
  	determine the number of ”field#”s added.
  Button, Expression Box,	None
  Hyperlink

• Note that all of the above “element” elements also have the attribute value “minOccurs=0”, but it has been omitted for clarity. Also note that the pound sign (#) represents a number to make each element name unique. For example: field1, field2, and field3.
• For the above example, when a component is added to the form-design screen112, thesystem100 will generate a hierarchical schema with a schema part including the above code;
• Likewise, each component built into an electronic form governs how the component is displayed and information within it handled. Each component built into an electronic form, for instance, governs the look, display, orientation, and size of data-entry field(s), as well as how and where information entered into these data-entry field(s) is mapped, including to a document governed by a corresponding hierarchical schema.
• The set of components available for building the electronic form can be extensible. A developer, by specifying the criteria above (for instance, the look, display, orientation, whether it allows nested components, and so forth) can create a new component that a designer can use to build an electronic form. A developer-created component, like the pre-existing components, can have an appropriate associated schema part from which to build a corresponding hierarchical schema.
• Once thesystem100 changes the hierarchical schema and electronic form (block408), it proceeds to block410 to display the electronic form and hierarchical schema, or to block414, to complete the process and produce the electronic form and hierarchical schema.Block410 will be discussed first below, followed later by a discussion ofblock414.
• In theblock410, theuser interface128 displays the electronic form and/or hierarchical schema. Hierarchical schemas can be represented in various ways, including by visually showing the hierarchical structure of the hierarchical schema. One example of this is the indentations of the hierarchical schema set forth in the hierarchicalschema display area108 ofFIG. 2.
• Electronic forms can be displayed (to a designer or user) through various techniques, including by transforming the hierarchical schema or its data file into an electronic form. In one implementation, thesystem100 creates a display for an electronic form by applying an application written in a transformation language onto a hierarchical schema or its data file written in a machine language. This creates a rendering language document written in a rendering language which can be used to create the display. By way of example, the transformation language can include CSS or XSLT, the machine language XML, and the rendering language HTML or XHTML.
• Electronic forms can be represented in various ways. Theuser interface128 can display a design view of an electronic form to a designer to make it easy for a designer to understand the structure of the electronic form, or can show the electronic form without additional information. A design view of an electronic form can mimic the electronic form that will be seen by a user, such as set forth in form-design area112 ofFIG. 2. The design view can show components built into an electronic form with additional information showing details about the data-entry field or fields corresponding to the components to aid a designer, in understanding the components in the electronic form and altering the electronic form.
• Theuser interface128 can also display the electronic form and hierarchical schema in order for the designer to assess the electronic form and hierarchical schema after each change made by the designer. When the designer can quickly see the effect of his changes, the designer can more easily build an electronic form and hierarchical schema matching the designer's intended results. Once the electronic form is displayed, such as in the form-design area112; and the hierarchical schema is displayed (if desired) in the hierarchicalschema display area108, the designer can continue to make changes or end the process. Ending the process will be discussed as part of theblock414, described below.
• Whether theuser interface128 displays the electronic form or the electronic form and hierarchical schema, the display should show changes made by a designer, such as adding a data-entry field and schema part by selecting and/or inserting a new component.
• Continuing the example above (where a designer chooses thetext box302 from thecomponent display area110 ofFIG. 5 and places thetext box302 in the upper left corner of the form-design area112), thedesign application126 will build an electronic form and hierarchical schema based on the identity and placement of the component. Using the exemplary code set forth above, thedesign application126 can build a hierarchical schema with a schema part including the code: <element name='string1” type='string”/>. This code can be displayed on thescreen102, but because most designers are more comfortable with a graphical display, the schema part can be displayed as an icon and text, such as with aschema part string1604 ofFIG. 6.
• Also in this example, thedesign application126 builds an electronic form with a text box component and displays it as set forth inFIG. 6, with a text box data-entry field602 in the form-design area112.
• One of the advantages of thedesign application126, and the method it employs, is that the electronic form and hierarchical schema can be built incrementally. That is to say, with each component chosen, or in some implementations with each other action taken that will affect the construction of the electronic form and hierarchical schema, the electronic form and hierarchical schema are altered. This incrementalism allows a designer to quickly see how the electronic form and hierarchical schema are changing with each change made by the designer. The designer does not have to work on either a form or a schema and then save the form or schema to see how the corresponding schema or form looks or performs. Instead, as the designer makes a change, it is reflected in the electronic form and hierarchical schema. This makes designing an electronic form and hierarchical schema easy and intuitive.
• In one implementation, thedesign application126 can reflect each change made by a designer to both the electronic form and hierarchical schema so quickly that the designer sees it in real time, regardless of whether the change was made to the electronic form by altering the form-design area112 or to the hierarchical schema by altering the hierarchicalschema display area110. By so doing, the designer can more easily design electronic forms and hierarchical schemas.
• Once a component has been added (or altered, discussed below), thedesign application126 displays the form and hierarchical schema as set forth above. With the new change shown, thedesign application126 continues to enable the designer to add components to the electronic form, returning to block404, or alter an existing component, block412.
• If the designer chooses to add another component, thedesign application126 enables him to do so in a manner similar to picking the first component as described above. Theelectronic form202 ofFIG. 2 is one such example of an electronic form built from many components.
• FIG. 7 shows anexemplary screen display700 showing the continued building of an electronic form. Here, the designer chose another component (thecheck box312 ofFIG. 6) to add to the electronic form and hierarchical schema shown inFIG. 6. In response to the designer's choice, thedesign application126 added aBoolean box702. As shown in thescreen display700, theBoolean box702 looks like a small check box (which can be filled with a check mark or left empty by a user) and is labeled “Boolean 1”. Also in response to the designer's choice, thedesign application126 altered the hierarchical schema to include a Boolean schema part704 (labeled “boolean1”) corresponding to theBoolean box702.
• FIG. 8 shows anexemplary design screen800 showing the continued building of an electronic form. Thedesign screen800 shows the electronic form and hierarchical schema fromFIGS. 6 and 7, and the results of the designer continuing to choose components. Through this process of adding components to the form-design area112, a designer can build everything from a simple electronic form, such as shown inFIG. 6, to a moderately complex form, such as shownFIG. 8, to a large, complex form, such as shown inFIG. 2. As thedesign application126 builds an electronic form, it builds a corresponding hierarchical schema.FIG. 2 shows an example of a hierarchical schema, displayed in hierarchicalschema display area108 ofFIG. 2, corresponding to an electronic form, in this case theelectronic form202 ofFIG. 2.
• A designer can simply make a change, like adding a component, to the electronic form or hierarchical schema and see the change applied to both the electronic form and hierarchical schema. In this sense, the electronic form and hierarchical schema are actively linked. This active linkage makes designing and changing electronic forms and hierarchical schemas quicker easier, and more intuitive.
• Thedesign application126 links the electronic form and the hierarchical schema by mapping each component within an electronic form to each schema part in the corresponding hierarchical schema. In one implementation, thedesign application126 maps them with XPath pointers.
• In theblock412, thedesign application126 enables a designer to select and alter existing components included in an electronic form and hierarchical schema. Thedesign application126 allows the designer to intuitively and easily alter the electronic form and hierarchical schema, such as by including editing tools familiar to designers that know word-processing techniques. A designer can change a component stylistically (such as the font, color, size, and the like) and structurally (such as by changing a text box to a Boolean box, and whether or to which other components the component governs or is subordinate). A designer can make these changes also by altering how a component (such as one displayed as a data-entry field) is represented on an electronic form. For example, a designer can click on a component on the form-design screen112, change the style, move it, delete it, and the like. As the designer makes changes, thedesign application126 alters the hierarchical schema to continue to correspond to the altering electronic form.
• FIG. 8 shows theexemplary design screen800, which provides a design view of an electronic form and its corresponding hierarchical schema, shown in thedesign area112 and the hierarchicalschema display area108, respectively. To enable the designer to make changes to a component, the design application126 (through the user interface128) enables the designer to click on components displayed in the design view of the electronic form. One such component a text box data-entry field802 (labeled “String 5”), is shown as an example. Once the designer selects a component, in this example the text box data-entry field802, thedesign application126 provides the designer with multiple options to change the data-entry field. As seen in a design screen900 (described below), thedesign application126 provides options in a way comfortable to a designer familiar with common word-processing techniques and icons. If the designer clicked on the text box data-entry field802 ofFIG. 8, thedesign application126 can provide multiple pop-up menus of options for the designer.
• FIG. 9 sets forth theexemplary design screen900 including multiple ways in which thedesign application126 provides options for a designer. These include acomponent context menu902 and astructure submenu904. In this example, thedesign application126 enables the designer to change the electronic form and hierarchical schema by changing a representation of a component in the form-design area112 (such as a data-entry field or accompanying graphics and text). Also, thedesign application126 enables the designer to cut the component and move it (through selection and deleting or dragging the component), and change its font, borders, shading, and other style changes (through the component context menu902), as well as change its structure (through the structure submenu904). In this example, the designer changes the component by changing the structure of a data-entry field corresponding to the component (the text box data-entry field802) into a date picker data-entry field by selecting adate picker component906.
• Also in theblock412, thedesign application126 enables a designer to alter a schema part directly through selecting it from a hierarchical schema. It can do so by allowing the designer to change an electronic form indirectly by making a change to the hierarchical schema. Thedesign application126 enables this because, while many designers may prefer to build an electronic form and hierarchical schema by changing an electronic form through a form-design screen, such as thedesign screen112, some designers will be familiar and comfortable enough with hierarchical schemas to change them through a representative display of the hierarchical schema, such as the hierarchicalschema display area108. In this way, the designer can alter or add schema parts in the hierarchical schema, which may be associated with components reflected in the electronic form. Once the designer has made a change, thedesign application126 changes the electronic form and hierarchical schema to reflect the alteration (block408).
• FIG. 10 shows an example of the hierarchicalschema display area108, and how it can be used by a designer to alter a hierarchical schema. In this example, a designer selected a schema part entitled “element” (an element1002). Once chosen, thedesign application126 prompts the designer, asking for information, such as through achange inquiry window1004. Using thewindow1004, thedesign application126 enables the designer to make various changes to theelement1002. He can change, for instance, the data type and default value allowed for theelement1002 and its corresponding data-entry field in an electronic form.
• Also as part of this example, thedesign application126 presents the designer with the current name, type, and data type of a selected schema part. The designer can then make changes by altering these current parameters of the selected schema part, such as set forth in thechange inquiry window1004 by changing the name to “myNewField” from “element” and the data type to “Text (string)” from “Whole Number (integer)”. Thedesign application126 also enables the designer to make other changes to a schema part, such as whether or not it repeats, has a default value, or can be blank.
• Also as part of theblock412, thedesign application126 allows a designer to alter components by adding to, deleting from, or otherwise changing schema parts (whether they are schema parts governing or subordinate to other schema parts or otherwise).
• FIG. 10 shows an example of a pop-up window with which thedesign application126 can enable a designer to alter schema parts. With analter window1006, the designer can add or delete aspects of a schema part, set a default value of the schema part, name the schema part, make it repeating or not, and establish whether or not it is allowed to be blank. In addition to these data parameters, thedesign application126 can enable the designer to make other changes to a schema part, such as to how it is validated, its script, and other details.
• As part of enabling the designer to makes these changes, thedesign application126 makes appropriate changes to the structure of the hierarchical schema and electronic form. If the designer deletes a component, for instance, thedesign application126 may delete the code corresponding to the component from the hierarchical schema and the electronic form.
• Assume, for example, that the designer chose to delete a repeatingsection804 from the electronic form shown in thedesign screen800 ofFIG. 8. With this selection made, thedesign application126 deletes a “repeating_item”schema part816 and its subordinate stringhierarchical schema parts818,820, and822 (entitled “string2”, “string3”, and “string4”) from the hierarchical schema. To do so thedesign application126 deletes the following code from the hierarchical schema:

  	<element name=”repeating_item”>
  	<complexType>
  	<sequence>
  	<element name=”string2” type=”string”/>
  	<element name=”string3” type=”string”/>
  	<element name=”string4” type=”string”/>
  	</complexType>
  	</element>
  	</sequence>
  	</complexType>
  	</element>

• Subsequent to this deletion, thedesign application126 deletes the component from the electronic form. In this example, thedesign application126 deletes the repeatingsection804 and its subordinate repeating string data-entry fields: a repeating string data-entry field810 (labeled “String 2:”); a repeating string data-entry field812 (labeled “String 3:”); and a repeating string data-entry field814 (labeled “String 4:”). This deletion can be shown immediately in the design view of the electronic form in thedesign screen800 by thedesign application126. By immediately showing the deletion in the electronic form and the hierarchical schema, thedesign application126 and theuser interface128 enable the designer to more easily and quickly customize the form to fit his or her preferences.
• According to block414, when finished, the end product is an electronic form and a corresponding hierarchical schema. The electronic form created can be a transformation-language document, and can be written in CSS, XSLT, or otherwise. Hierarchical schemas corresponding to these electronic forms can also be written in various languages, which will be described in greater detail below.
• One example of an electronic form created by thedesign application126 is the purchase orderelectronic form202 viewed in the form-design area112 ofFIG. 2. Thiselectronic form202, once finished and presented to an end user, can be used by that user to key in information into data-entry fields. After entry of information, the information can be stored in a markup-language document, such as one written in XML. The information stored can conform to a hierarchical schema corresponding to the electronic form, thereby allowing easy use and/or transfer of information stored in the markup-language document. The hierarchical schema to which the markup-language document conforms can be written in various languages, including schemas written to govern markup languages (such as XML). Schemas governing XML documents are commonly called XML Schemas, DTD (Document Type Definition) schemas, and XDR (XML-Data Reduced) schemas.
• Thus, a designer not knowledgeable about transformation-language documents (like an electronic form written in CSS), hierarchical schemas, or programming can, easily and with no specialized skills, create an electronic form and corresponding hierarchical schema.
• Thedesign application126 can even create electronic forms that are XSLT transformation-language documents, which is especially complex, and corresponding hierarchical schemas that are XML schemas. In this case, a designer having little knowledge about the XSLT language can create, using XSLT transformation-language components as an example, an electronic form that is an XSLT transformation-language document and a corresponding hierarchical schema which is a schema capable of governing XML documents, such as XML Schema.
• The hierarchical schema can be written in many languages, follow various standards, or be a set of tables in a database. Hierarchical schemas can do more than a linear or flat list; they can include, for example, a schema part that governs or contains another schema part that corresponds to a component of a different type than that of the governing schema part. Thus, these types of schemas can allow for a governing schema part to correspond to a text box component, for instance, and at the same time govern a Boolean component.
• Hierarchical schemas can govern many different documents. Because of this, an electronic form relating to a hierarchical schema can have thousands of different users keying information into thousands of different documents, all of which can be governed by the one hierarchical schema.
• Building a Hierarchical Schema
• Thesystem100 enables a designer to incrementally build an electronic form and corresponding hierarchical schema.
• Because the concept of structuring data hierarchically can be difficult for designers to grasp easily and readily, but many users readily understand structuring information spatially, thedesign application126 can enable users to incrementally create spatially structured electronic forms. These electronic forms are incrementally converted into hierarchically structured schemas, thus making it easier for a designer to create electronic forms that take advantage of hierarchically structured data.
• The hierarchical aspect of the hierarchical schema allows it to correspond to many different types of structures and components in an electronic form. A designer can, for instance, build an electronic form with various structures, like repeating tables and lists. These repeating tables and lists are well suited to a hierarchical schema because of its hierarchical aspect.
• A hierarchical schema is structured; in other words, some schema parts may be governed or affected by other schema parts. With the exception of every schema part's subordination to the root schema part, which governs all other schema parts, each schema part may or may not be subordinate to another schema part. In the hierarchicalschema display area108 ofFIG. 2 for instance, the root schema part is the schema part labeled “PurchaseOrder”. The next six schema parts, “referenceNumber” to “chargeTo”, are subordinate to (or governed by) only the root schema part, “PurchaseOrder”. Conversely, the six schema parts labeled “prefix” to “singleName” are also governed by the schema part labeled “deliveryTo”.
• Thedesign application126 can build a hierarchical schema hierarchically. It can do so by receiving instructions from a designer as to how to build the hierarchical schema, including how to arrange each schema part as subordinate to or governing another. A designer can, for instance, instruct thedesign application126 to make a particular component subordinate to or govern other components. A designer can also instruct thedesign application126 to make a particular schema part subordinate to or govern other schema parts. In either case, thedesign application126 can build a hierarchical schema and electronic form based on how components or schema parts govern or are subordinate to other components or schema parts. By enabling a designer to give thedesign application126 instructions in various ways, including typed-in instructions, clicking on icons, and dragging and dropping icons for schema parts or components, the designer's experience can be made easy and intuitive.
• Some of the ways thedesign application126 can receive instructions as to how to build an electronic form and hierarchical schema hierarchically can include ways in which a designer will not need to know how or even that a hierarchical schema is being built. Many designers may not understand hierarchical schemas, or may just want to build a hierarchical schema (and, typically, an electronic form) in an easy, graphical, and intuitive manner.
• FIG. 11 shows aprocess1100 by which thedesign application126 enables a designer to give instructions graphically and, using the instructions, determine a governance or subordination of schema parts in a hierarchical schema. As set forth inblock1102, thedesign application126 enables a designer to give instructions graphically. In this way, a designer can give instructions (like placing a component in a particular location of the form-design area112) to thedesign application126 from which it can infer how the designer wishes a hierarchical schema to be built.
• Thedesign application126 enables a designer to input his or her preference for a component to be subordinate and/or governing, such as by placing a component's icon or a mouse-pointer beneath, below, within, or otherwise relative to another, existing component (whether when first placed or later moved) To aid the designer to give the designer's intended input to thedesign application126, it enables a designer to see how each component is governed by or subordinate to other components. Thedesign application126, in one implementation, displays subordination areas to graphically indicate which components govern or are subordinate to others. Some of these components inherently contain other components, and so are shown with subordination areas containing data-entry fields in thedisplay area112; some are altered by the designer to contain other components.
• InFIG. 12, for example, anexemplary design screen1200 shows how thedesign application126 can enable a designer to place components subordinate to and/or governing other components by placing them in particular places in thedesign screen1200.FIG. 12 shows subordination areas marked by boxes, into which a designer can place a component to be subordinate to another component. If the designer places a component outside all subordination areas, the component will be governed by only the root schema part. These subordination areas show components as subordinate or governing in the electronic form and hierarchical schema.
• In this example, aproduct schema part1202 is shown to be subordinate (governed by) the “productSection”schema part1204 by the product schema part's1202 correspondingproduct component1206 being within aproductSection box1208 marked with a tab entitled “Section”. Also in this example, acompany schema part1210 is shown to be governed by acompanySection schema part1212 and theproductSection schema part1204 by the company schema part's1210.company component1214 being within acompanySection box1216 marked with a tab entitled “Section”.
• Thus, thecompany schema part1210 is governed by two schema parts (1212 and1204) as well as theroot schema part1218 entitled “form”. Continuing this example, awebsite component1220 and itsschema part1222 are shown to be governed by the companySection schema part1212 (through the component being within the companySection box1216), theproductSection schema part1204, and theroot schema part1218. Likewise, astreet component1224 and itsschema part1226, acity component1228 and itsschema part1230, and astate component1232 and its schema part1234 are shown to be governed by anaddressSection schema part1236, thecompanySection schema part1212, theproductSection schema part1204, and theroot schema part1218.
• Thus, thedesign application126 can show a designer which components govern or are subordinate to other components. Similarly, thedesign application126 can infer, in some implementations, which components govern or are subordinate to other components based upon where a component is placed by a designer relative to another component, such as by a designer placing a component within a subordination area, e.g., theproduct section box1208.
• Atblock1104, thedesign application126 determines to which other component(s) a placed or moved component is graphically subordinate. It can determine, for example, that thecompany component1214 and thewebsite component1220 are subordinate to thecompanySection schema part1212 through being within thecompanySection box1216. With this determination, thedesign application126 builds the hierarchical schema to represent this subordination (block1106). Thedesign application126 can determine this incrementally, such as when a component is added or moved into a subordination area.
• Thedesign application126 adds or rearranges schema parts to represent each component's relationship to the other components. Continuing the above example, for the relationship between the components in the form-design area112 ofFIG. 12, thedesign application126 builds a hierarchical schema that corresponds to the form-design area112, set forth in the hierarchicalschema display area108, also ofFIG. 12. The hierarchicalschema display area108, for example, includes theroot schema part1218, though no corresponding component/box is shown in the form-design area112.
• The hierarchical schema displayed in hierarchical schema display area,108 includes schema parts corresponding to components and reflecting the relationships between the components in the form-design area112. It shows here that theproduct schema part1202 and thewebsite schema part1222 correspond to theproduct component1206 and thewebsite component1220. The hierarchicalschema display area108 shows that these components and their corresponding schema parts (1202 and1222) are subordinate toschema parts1204 and1218.
• Thedesign application126 builds this hierarchical structure into the hierarchical schema by subordinating schema parts to other schema parts. Lastly, thedesign application126 can build the hierarchical schema to show that schema parts are subordinate to other parts by being placed to the right of those schema parts.
• The example set forth inFIG. 12 shows various types of components and schema parts, but is not intended to limit the abilities of thedesign application126, theuser interface128, or thesystem100; other types of components and ways to present them can be used.
• A Computer System
• FIG. 13 shows an exemplary computer system that can be used to implement the processes described herein.Computer1342 includes one or more processors orprocessing units1344, asystem memory1346, and abus1348 that couples various system components including thesystem memory1346 toprocessors1344. Thebus1348 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. Thesystem memory1346 includes read only memory (ROM)1350 and random access memory (RAM)1352. A basic input/output system (BIOS)1354, containing the basic routines that help to transfer information between elements withincomputer1342, such as during start-up, is stored inROM1350.
• Computer1342 further includes ahard disk drive1356 for reading from and writing to a hard disk (not shown), amagnetic disk drive1358 for reading from and writing to a removablemagnetic disk1360, and anoptical disk drive1362 for reading from or writing to a removableoptical disk1364 such as a CD ROM or other optical media. Thehard disk drive1356,magnetic disk drive1358, andoptical disk drive1362 are connected to thebus1348 by anSCSI interface1366 or some other appropriate interface. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data forcomputer1342. Although the exemplary environment described herein employs a hard disk, a removablemagnetic disk1360 and a removableoptical disk1364, it should be appreciated by those skilled in the art that other types of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROMs), and the like, may also be used in the exemplary operating environment.
• A number of program modules may be stored on thehard disk1356,magnetic disk1360,optical disk1364,ROM1350, orRAM1352, including anoperating system1370, one or more application programs1372 (such as a design application),other program modules1374, andprogram data1376. A user may enter commands and information intocomputer1342 through input devices such as akeyboard1378 and apointing device1380. Other input devices (not shown) may include a, microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to theprocessing unit1344 through an interface1382 that is coupled to thebus1348. Amonitor1384 or other type of display device is also connected to thebus1348 via an interface, such as avideo adapter1386. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) such as speakers and printers.
• Computer1342 commonly operates in a networked environment using logical connections to one or more remote computers, such as a remote computer1388. The remote computer1388 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative tocomputer1342. The logical connections depicted inFIG. 13 include a local area network (LAN)1390 and a wide area network (WAN)1392. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.
• When used in a LAN networking environment,computer1342 is connected to the local network through a network interface oradapter1394. When used in a WAN networking environment,computer1342 typically includes amodem1396 or other means for establishing communications over thewide area network1392, such as the Internet. Themodem1396, which may be internal or external, is connected to thebus1348 via aserial port interface1368. In a networked environment, program modules depicted relative to thepersonal computer1342, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
• Generally, the data processors ofcomputer1342 are programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer's primary electronic memory. The system described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the blocks described, in conjunction with a microprocessor or other data processor. The system described can also include the computer itself when programmed according to the methods and techniques described herein.
• For purposes of illustration, programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer.
Conclusion
• The above-described system and method enables a designer to easily and incrementally create electronic forms and corresponding hierarchical schemas, even if the designer has only basic skills. The above-described system and method also allows a designer to create, with the click of a mouse, electronic forms written in XSLT and hierarchical schemas written in XML Schema. In addition, the above system and method enables a designer to view changes he is making in real-time to an electronic font and hierarchical schema. Although the system and method has been described in language specific to structural features and/or methodological acts, it is to be understood that the system and method defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed system and method.

Claims (20)

1. A method comprising:

displaying a plurality of components;

receiving input selecting one of the components;

identifying the selected component;

building a hierarchical schema to include a schema part corresponding to the identified component;

building an electronic form to include a data-entry field corresponding to the selected component; and

displaying at least one of the electronic form and the hierarchical schema.

2. The method ofclaim 1, wherein the hierarchical schema and the electronic form are built simultaneously.

3. The method ofclaim 1, wherein building the hierarchical schema includes inferring properties for the schema part from properties of the identified component.

4. The method ofclaim 1, wherein building the hierarchical schema includes inferring, for the schema part, a data type and allowance of repeating data-entry fields from properties of the identified component.

5. The method ofclaim 1, further comprising:

receiving one or more of the plurality of components.

6. The method ofclaim 1, further comprising:

receiving input selecting a criteria to create a custom component; and

creating the custom component based on the selected criteria,

wherein the plurality of components includes the custom component.

7. The method ofclaim 1, further comprising:

receiving input selecting a criteria to create a custom component;

creating the custom component based on the selected criteria; and

creating a custom schema part corresponding to the custom component,

wherein the plurality of components includes the custom component and building the hierarchical schema includes including the custom schema part if the identified component is the custom component.

8. The method ofclaim 1, further comprising:

receiving input selecting an option for the selected component, wherein the hierarchical schema and electronic form are built to reflect the selected option.

9. The method ofclaim 8, wherein the option includes a location for the component on a form-design area.

10. The method ofclaim 8, wherein the option includes a label for the component.

11. The method ofclaim 8, wherein the option includes replacing the component.

12. The method ofclaim 1, wherein the electronic form is written in a transformation language.

13. The method ofclaim 1, wherein the hierarchical schema is written in a markup language.

14. The method ofclaim 1, wherein the hierarchical schema is described using a formalized schema description language.

15. The method ofclaim 1, wherein the hierarchical schema is represented as a data store.

16. The method ofclaim 1, wherein the components include code written in XSLT.

17. The method ofclaim 1, further comprising inferring a data store from the hierarchical schema.

18. The method ofclaim 1, wherein building the hierarchical schema and the electronic form further comprises linking the hierarchical schema and the electronic form so that changes made in one are made simultaneously in the other.

19. The method ofclaim 18, wherein the hierarchical schema and the electronic form are linked using XPaths.

20. A system comprising:

a user-input device;

a computer having a display;

a user interface executable on the computer and configured to:

display components in a component display area of the display;

facilitate a designer's selection of the component; and

display a representation of the selected component in a form-design area of the display that corresponds to the selected component, and

a design application executable on the computer and configured to incrementally and simultaneously build an electronic form visually mimicking the form-design area of the display.

Images