U.S. patent application number 11/567133 was filed with the patent office on 2007-05-03 for building electronic forms.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Ned B. Friend, Sharma K. Hendel, Matthew J. Kotler, Shuk-Yan Lai, Thomas R. Lawrence, Laurent Mollicone, Jean D. Paoli, Jason Whitmarsh.
Application Number | 20070100877 11/567133 |
Document ID | / |
Family ID | 32988592 |
Filed Date | 2007-05-03 |
United States Patent
Application |
20070100877 |
Kind Code |
A1 |
Paoli; Jean D. ; et
al. |
May 3, 2007 |
Building Electronic Forms
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.
Inventors: |
Paoli; Jean D.; (Kirkland,
WA) ; Mollicone; Laurent; (Kirkland, WA) ;
Friend; Ned B.; (Seattle, WA) ; Kotler; Matthew
J.; (Kenmore, WA) ; Lawrence; Thomas R.;
(Seattle, WA) ; Lai; Shuk-Yan; (Redmond, WA)
; Hendel; Sharma K.; (Seattle, WA) ; Whitmarsh;
Jason; (Seattle, WA) |
Correspondence
Address: |
LEE & HAYES PLLC
421 W RIVERSIDE AVENUE SUITE 500
SPOKANE
WA
99201
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
32988592 |
Appl. No.: |
11/567133 |
Filed: |
December 5, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10395505 |
Mar 24, 2003 |
|
|
|
11567133 |
Dec 5, 2006 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.102 |
Current CPC
Class: |
G06F 40/143 20200101;
G06F 40/174 20200101 |
Class at
Publication: |
707/102 |
International
Class: |
G06F 7/00 20060101
G06F007/00 |
Claims
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 of claim 1, wherein the hierarchical schema and the
electronic form are built simultaneously.
3. The method of claim 1, wherein building the hierarchical schema
includes inferring properties for the schema part from properties
of the identified component.
4. The method of claim 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 of claim 1, further comprising: receiving one or more
of the plurality of components.
6. The method of claim 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 of claim 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 of claim 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 of claim 8, wherein the option includes a location
for the component on a form-design area.
10. The method of claim 8, wherein the option includes a label for
the component.
11. The method of claim 8, wherein the option includes replacing
the component.
12. The method of claim 1, wherein the electronic form is written
in a transformation language.
13. The method of claim 1, wherein the hierarchical schema is
written in a markup language.
14. The method of claim 1, wherein the hierarchical schema is
described using a formalized schema description language.
15. The method of claim 1, wherein the hierarchical schema is
represented as a data store.
16. The method of claim 1, wherein the components include code
written in XSLT.
17. The method of claim 1, further comprising inferring a data
store from the hierarchical schema.
18. The method of claim 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 of claim 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.
Description
RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] For these reasons, creating electronic forms and
corresponding schemas can be difficult, time consuming, and require
a programmer of significant skill.
SUMMARY
[0008] 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.
[0009] 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.
[0010] 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
[0011] FIG. 1 illustrates a system with a display screen, computer,
and user-input devices. The system implements a method for
designing electronic forms.
[0012] 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.
[0013] FIG. 3 illustrates an exemplary component display area.
[0014] FIG. 4 is a flow diagram of an exemplary process for
generating electronic forms and hierarchical schemas.
[0015] FIG. 5 illustrates an exemplary screen display showing a
component display area and a blank form-design area.
[0016] FIG. 6 illustrates an exemplary screen display showing part
of a hierarchical schema display area, a component display area,
and a form-design area.
[0017] FIG. 7 illustrates an exemplary screen display showing part
of a hierarchical schema display area, a component display area,
and a form-design area.
[0018] FIG. 8 illustrates an exemplary screen display showing a
hierarchical schema display area and a form-design area.
[0019] 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.
[0020] FIG. 10 illustrates an exemplary hierarchical schema display
area, a change inquiry window, and an add window.
[0021] FIG. 11 is a flow diagram of an exemplary process for
building a hierarchical schema.
[0022] FIG. 12 illustrates an exemplary screen display showing a
hierarchical schema display area and a form-design area.
[0023] FIG. 13 is a block diagram of a computer system that is
capable of supporting an electronic-form and hierarchical-schema
generation process.
[0024] The same numbers are used throughout the disclosure and
figures to reference like components and features.
DETAILED DESCRIPTION
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] System Architecture
[0030] 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.
[0031] FIG. 1 shows an exemplary system 100, which includes a
screen 102, user-input devices 104, and a computer 106.
[0032] The user-input devices 104 can include any device allowing a
computer to receive a designer's preferences, such as a keyboard
114, other device(s) 116, and a mouse 118. The other input devices
116 can include a touch screen, a voice-activated input device, a
track ball, and any other device that allows the system 100 to
receive input from a designer. The computer 106 includes a
processing unit 120 and random access memory and/or read-only
memory 122 including applications, such as an operating system 124
and a form and a design application 126, which includes a user
interface 128. The computer 106 communicates with a designer
through the screen 102 and the user-input devices 104.
[0033] The screen 102 includes three displays or screen areas: a
hierarchical schema display area 108; a component display area 110;
and a form-design area 112. 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.
[0034] FIG. 2 shows an exemplary design screen 200, including an
example of the form-design area 112 and the hierarchical schema
display area 108 (entitled "Data Source"). Partially within the
form-design area 112 is a design view of an electronic form 202.
The electronic form 202 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. This
electronic form 202 is being built from components chosen by a
designer. The components chosen create the data-entry fields shown
in the electronic form 202. These data-entry fields correspond to
parts of a hierarchical schema, the parts being shown through the
icons displayed in the hierarchical schema display area 108. The
icons displayed are a representation of part of a file of
hierarchical schema arranged into a tree structure.
[0035] FIG. 3 shows an example of components from which a designer
can choose, which are displayed here at the component display area
110. These various components include a text box 302, a rich text
box 304, a drop-down list box 306, a list box 308, a date picker
310, a check box 312, an option button 314, a section 316, an
optional section 318, a repeating section 320, a repeating table
322, a bulleted list 324, a numbered list 326, a plain list 328, a
button 330, and hyperlink 332. 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.
[0036] With the listed components and other components the system
100 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 the
electronic form 202 in the form-design area 112 of FIG. 2. The
process used to build an electronic form and hierarchical schema
from components will be set forth in greater detail below.
[0037] The above devices and applications are merely
representative, and other known devices and applications may be
substituted for or added to those shown in FIG. 1. One example of
another known device that can be substituted for those shown in
FIG. 1 is the device shown in FIG. 13. Other examples include
portable, handheld, or wireless devices.
[0038] Techniques for Building Forms and Hierarchical Schemas
Overview
[0039] A system, such as the system 100 of FIG. 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. The system 100 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 the system 100.
[0040] FIG. 4 shows a process 400 for generating an electronic form
and a corresponding hierarchical schema. The process 400 is
illustrated as a series of blocks representing individual
operations or acts performed by the system 100. The process 400 may
be implemented in any suitable hardware, software, firmware, or
combination thereof. In the case of software and firmware, the
process 400 represents a set of operations implemented as
computer-executable instructions stored in the memory 122 and
executable by the processing unit 120.
Displaying Components and Form-Design Area
[0041] At block 402, the user interface 128 displays components and
a form-design area. It does so to enable a designer to graphically
design an electronic form.
[0042] FIG. 5 shows a design screen 500 created by the user
interface 128, having an example of the component display area 110
and a blank example of the form-design area 112. The form-design
area 112 is displayed to make it easy for a designer without
typical programming skills to create an electronic form and
corresponding hierarchical schema.
[0043] To make it easy, the user interface 128 can provide an
editing experience to a designer similar to that commonly provided
in word-processing systems. The user interface 128 can, for
instance, work like a word-processing system by providing similar
font controls and options. In FIG. 5, for example, the user
interface 128 displays the form-design area 112 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 (in
FIG. 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
display 502 of FIG. 5.
[0044] Also, as stated elsewhere herein, changes made by the
designer to the form-design area 112 can be reflected in the
form-design area 112 instantaneously (from the perspective of the
designer), further making the design process similar to a typical
word-processing experience. By so doing, the user interface 128
makes designing an electronic form simpler and more intuitive for a
person skilled in word-processing.
[0045] The components are displayed by the user interface 128 in
the component display area 110 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, the user interface 128 displays icons
and/or text to inform the designer, such as with the icons and text
set forth in the component display area 110 set forth in FIGS. 3
and 5. In FIG. 3, for example, the text box 302 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 box
302 ("Text Box") is also descriptive.
[0046] With the component display area 110 and the form-design area
112 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 a design sub-process 403, which includes blocks 404 to
412. The sub-process 403 includes blocks used to describe the
action and interaction of the designer and the system 100. When the
designer has finished with the electronic form and hierarchical
schema, the design application 126 produces the resulting
electronic form and hierarchical schema (block 414). The process
403 and the block 414 will be described in greater detail
below.
[0047] When the component display area 110 and the form-design area
112 are presented, the designer can pick a component from the list
of components in the component display area 110 for insertion into
the form-design area 112 (block 404). The designer can pick from
components in various ways, including through the mouse 118, the
other devices 116 (such as a touch screen, track ball,
voice-activation, and the like), and through the keyboard 114,
which are shown in FIG. 1. To grant flexibility to the designer,
the system 100 enables the designer to move the component in the
form-design area 112 to where she desires.
[0048] A designer can pick a component, for example, by dragging
and dropping (from the component display area 110) a component's
icon onto a form-design area 112 shown in FIG. 5. The designer can
pick a component to drag and drop with various devices, such as
with the mouse 118 or commands entered through the keyboard 114. In
FIG. 5, the designer clicks on the icon and text for the text box
302 to select it.
[0049] 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.
[0050] FIG. 6 shows an exemplary screen display 600 showing what
the design application 126 creates after a designer selects the
text box 302 in FIG. 5 (also shown in FIG. 6). In this example, the
system 100 creates a text box data-entry field 602, which looks
like a gray box for entry of text and is labeled "String 1:", in
response to the designer's selection. The design application 126
enables the designer to continue building his electronic form by
selecting components, thereby creating data-entry fields.
Building an Electronic Form and Hierarchical Schema
[0051] Once the system 100 receives a selection of a component and
the placement for the component, the system 100 can identify which
component was selected, identify the placement for that component
on the form-design area 112, 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 in blocks
406, 408, 410, and 414 of FIG. 4, which will be described
below.
[0052] In block 406, the design application 126 identifies which
component was selected. The system 100 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 the component
display area 110 shown in FIGS. 3, 5, 6, and 7.
[0053] Also in the block 406, the design application 126 identifies
where a component is placed in the form-design area 112. 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.
[0054] If, for example, a designer chooses the text box 302 from
the component display area 110 of FIG. 5, and places the text box
302 in the upper left corner of the form-design area 112, the
design application 126 will identify the component and its
placement. In this example, the design application 126 will
identify that the component chosen was the text box 302 and the
placement was a particular spot in the upper left corner of the
form-design area 112. With this information, the system 100
proceeds to build the electronic form and hierarchical schema,
which will be described in part using FIGS. 5 and 6.
[0055] In block 408, the design application 126 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, the design application 126 changes the
hierarchical schema and electronic form by building in the added
component. When an existing component is altered (discussed in
greater detail below), the design application 126 changes the
electronic form and hierarchical schema to reflect that
alteration.
[0056] The structure of each component placed into the form-design
area 112 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 application 126) 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).
[0057] 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:
TABLE-US-00001 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
[0058] 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.
[0059] For the above example, when a component is added to the
form-design screen 112, the system 100 will generate a hierarchical
schema with a schema part including the above code;
[0060] 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.
[0061] 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.
[0062] Once the system 100 changes the hierarchical schema and
electronic form (block 408), it proceeds to block 410 to display
the electronic form and hierarchical schema, or to block 414, to
complete the process and produce the electronic form and
hierarchical schema. Block 410 will be discussed first below,
followed later by a discussion of block 414.
[0063] In the block 410, the user interface 128 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 hierarchical schema display area 108 of FIG. 2.
[0064] 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, the system 100 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.
[0065] Electronic forms can be represented in various ways. The
user interface 128 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 area 112 of FIG. 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.
[0066] The user interface 128 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 area
112; and the hierarchical schema is displayed (if desired) in the
hierarchical schema display area 108, the designer can continue to
make changes or end the process. Ending the process will be
discussed as part of the block 414, described below.
[0067] Whether the user interface 128 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.
[0068] Continuing the example above (where a designer chooses the
text box 302 from the component display area 110 of FIG. 5 and
places the text box 302 in the upper left corner of the form-design
area 112), the design application 126 will build an electronic form
and hierarchical schema based on the identity and placement of the
component. Using the exemplary code set forth above, the design
application 126 can build a hierarchical schema with a schema part
including the code: <element name='string1" type='string"/>.
This code can be displayed on the screen 102, 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 a schema
part string1 604 of FIG. 6.
[0069] Also in this example, the design application 126 builds an
electronic form with a text box component and displays it as set
forth in FIG. 6, with a text box data-entry field 602 in the
form-design area 112.
[0070] One of the advantages of the design application 126, 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.
[0071] In one implementation, the design application 126 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 area 112 or to the
hierarchical schema by altering the hierarchical schema display
area 110. By so doing, the designer can more easily design
electronic forms and hierarchical schemas.
[0072] Once a component has been added (or altered, discussed
below), the design application 126 displays the form and
hierarchical schema as set forth above. With the new change shown,
the design application 126 continues to enable the designer to add
components to the electronic form, returning to block 404, or alter
an existing component, block 412.
[0073] If the designer chooses to add another component, the design
application 126 enables him to do so in a manner similar to picking
the first component as described above. The electronic form 202 of
FIG. 2 is one such example of an electronic form built from many
components.
[0074] FIG. 7 shows an exemplary screen display 700 showing the
continued building of an electronic form. Here, the designer chose
another component (the check box 312 of FIG. 6) to add to the
electronic form and hierarchical schema shown in FIG. 6. In
response to the designer's choice, the design application 126 added
a Boolean box 702. As shown in the screen display 700, the Boolean
box 702 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, the design application
126 altered the hierarchical schema to include a Boolean schema
part 704 (labeled "boolean1") corresponding to the Boolean box
702.
[0075] FIG. 8 shows an exemplary design screen 800 showing the
continued building of an electronic form. The design screen 800
shows the electronic form and hierarchical schema from FIGS. 6 and
7, and the results of the designer continuing to choose components.
Through this process of adding components to the form-design area
112, a designer can build everything from a simple electronic form,
such as shown in FIG. 6, to a moderately complex form, such as
shown FIG. 8, to a large, complex form, such as shown in FIG. 2. As
the design application 126 builds an electronic form, it builds a
corresponding hierarchical schema. FIG. 2 shows an example of a
hierarchical schema, displayed in hierarchical schema display area
108 of FIG. 2, corresponding to an electronic form, in this case
the electronic form 202 of FIG. 2.
[0076] 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.
[0077] The design application 126 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, the design application 126 maps them with
XPath pointers.
[0078] In the block 412, the design application 126 enables a
designer to select and alter existing components included in an
electronic form and hierarchical schema. The design application 126
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
screen 112, change the style, move it, delete it, and the like. As
the designer makes changes, the design application 126 alters the
hierarchical schema to continue to correspond to the altering
electronic form.
[0079] FIG. 8 shows the exemplary design screen 800, which provides
a design view of an electronic form and its corresponding
hierarchical schema, shown in the design area 112 and the
hierarchical schema display area 108, respectively. To enable the
designer to make changes to a component, the design application 126
(through the user interface 128) enables the designer to click on
components displayed in the design view of the electronic form. One
such component a text box data-entry field 802 (labeled "String
5"), is shown as an example. Once the designer selects a component,
in this example the text box data-entry field 802, the design
application 126 provides the designer with multiple options to
change the data-entry field. As seen in a design screen 900
(described below), the design application 126 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 field 802 of FIG. 8, the design application 126 can
provide multiple pop-up menus of options for the designer.
[0080] FIG. 9 sets forth the exemplary design screen 900 including
multiple ways in which the design application 126 provides options
for a designer. These include a component context menu 902 and a
structure submenu 904. In this example, the design application 126
enables the designer to change the electronic form and hierarchical
schema by changing a representation of a component in the
form-design area 112 (such as a data-entry field or accompanying
graphics and text). Also, the design application 126 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
menu 902), as well as change its structure (through the structure
submenu 904). 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 field 802) into a date
picker data-entry field by selecting a date picker component
906.
[0081] Also in the block 412, the design application 126 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. The design application 126 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 the design screen 112, 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 hierarchical schema display area 108. 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, the design
application 126 changes the electronic form and hierarchical schema
to reflect the alteration (block 408).
[0082] FIG. 10 shows an example of the hierarchical schema display
area 108, 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 element 1002). Once chosen, the design
application 126 prompts the designer, asking for information, such
as through a change inquiry window 1004. Using the window 1004, the
design application 126 enables the designer to make various changes
to the element 1002. He can change, for instance, the data type and
default value allowed for the element 1002 and its corresponding
data-entry field in an electronic form.
[0083] Also as part of this example, the design application 126
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 the change inquiry window 1004 by changing the name
to "myNewField" from "element" and the data type to "Text (string)"
from "Whole Number (integer)". The design application 126 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.
[0084] Also as part of the block 412, the design application 126
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).
[0085] FIG. 10 shows an example of a pop-up window with which the
design application 126 can enable a designer to alter schema parts.
With an alter window 1006, 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,
the design application 126 can enable the designer to make other
changes to a schema part, such as to how it is validated, its
script, and other details.
[0086] As part of enabling the designer to makes these changes, the
design application 126 makes appropriate changes to the structure
of the hierarchical schema and electronic form. If the designer
deletes a component, for instance, the design application 126 may
delete the code corresponding to the component from the
hierarchical schema and the electronic form.
[0087] Assume, for example, that the designer chose to delete a
repeating section 804 from the electronic form shown in the design
screen 800 of FIG. 8. With this selection made, the design
application 126 deletes a "repeating_item" schema part 816 and its
subordinate string hierarchical schema parts 818, 820, and 822
(entitled "string2", "string3", and "string4") from the
hierarchical schema. To do so the design application 126 deletes
the following code from the hierarchical schema: TABLE-US-00002
<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>
[0088] Subsequent to this deletion, the design application 126
deletes the component from the electronic form. In this example,
the design application 126 deletes the repeating section 804 and
its subordinate repeating string data-entry fields: a repeating
string data-entry field 810 (labeled "String 2:"); a repeating
string data-entry field 812 (labeled "String 3:"); and a repeating
string data-entry field 814 (labeled "String 4:"). This deletion
can be shown immediately in the design view of the electronic form
in the design screen 800 by the design application 126. By
immediately showing the deletion in the electronic form and the
hierarchical schema, the design application 126 and the user
interface 128 enable the designer to more easily and quickly
customize the form to fit his or her preferences.
[0089] According to block 414, 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.
[0090] One example of an electronic form created by the design
application 126 is the purchase order electronic form 202 viewed in
the form-design area 112 of FIG. 2. This electronic form 202, 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.
[0091] 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.
[0092] The design application 126 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.
[0093] 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.
[0094] 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
[0095] The system 100 enables a designer to incrementally build an
electronic form and corresponding hierarchical schema.
[0096] 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, the
design application 126 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.
[0097] 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.
[0098] 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
hierarchical schema display area 108 of FIG. 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".
[0099] The design application 126 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 the design application 126
to make a particular component subordinate to or govern other
components. A designer can also instruct the design application 126
to make a particular schema part subordinate to or govern other
schema parts. In either case, the design application 126 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 the design application
126 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.
[0100] Some of the ways the design application 126 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.
[0101] FIG. 11 shows a process 1100 by which the design application
126 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 in block 1102, the
design application 126 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
area 112) to the design application 126 from which it can infer how
the designer wishes a hierarchical schema to be built.
[0102] The design application 126 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 the design
application 126, it enables a designer to see how each component is
governed by or subordinate to other components. The design
application 126, 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 the display area 112; some are
altered by the designer to contain other components.
[0103] In FIG. 12, for example, an exemplary design screen 1200
shows how the design application 126 can enable a designer to place
components subordinate to and/or governing other components by
placing them in particular places in the design screen 1200. 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.
[0104] In this example, a product schema part 1202 is shown to be
subordinate (governed by) the "productSection" schema part 1204 by
the product schema part's 1202 corresponding product component 1206
being within a productSection box 1208 marked with a tab entitled
"Section". Also in this example, a company schema part 1210 is
shown to be governed by a companySection schema part 1212 and the
productSection schema part 1204 by the company schema part's 1210.
company component 1214 being within a companySection box 1216
marked with a tab entitled "Section".
[0105] Thus, the company schema part 1210 is governed by two schema
parts (1212 and 1204) as well as the root schema part 1218 entitled
"form". Continuing this example, a website component 1220 and its
schema part 1222 are shown to be governed by the companySection
schema part 1212 (through the component being within the
companySection box 1216), the productSection schema part 1204, and
the root schema part 1218. Likewise, a street component 1224 and
its schema part 1226, a city component 1228 and its schema part
1230, and a state component 1232 and its schema part 1234 are shown
to be governed by an addressSection schema part 1236, the
companySection schema part 1212, the productSection schema part
1204, and the root schema part 1218.
[0106] Thus, the design application 126 can show a designer which
components govern or are subordinate to other components.
Similarly, the design application 126 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., the product
section box 1208.
[0107] At block 1104, the design application 126 determines to
which other component(s) a placed or moved component is graphically
subordinate. It can determine, for example, that the company
component 1214 and the website component 1220 are subordinate to
the companySection schema part 1212 through being within the
companySection box 1216. With this determination, the design
application 126 builds the hierarchical schema to represent this
subordination (block 1106). The design application 126 can
determine this incrementally, such as when a component is added or
moved into a subordination area.
[0108] The design application 126 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 area 112 of FIG. 12, the design
application 126 builds a hierarchical schema that corresponds to
the form-design area 112, set forth in the hierarchical schema
display area 108, also of FIG. 12. The hierarchical schema display
area 108, for example, includes the root schema part 1218, though
no corresponding component/box is shown in the form-design area
112.
[0109] 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 area 112. It shows here that the product schema part
1202 and the website schema part 1222 correspond to the product
component 1206 and the website component 1220. The hierarchical
schema display area 108 shows that these components and their
corresponding schema parts (1202 and 1222) are subordinate to
schema parts 1204 and 1218.
[0110] The design application 126 builds this hierarchical
structure into the hierarchical schema by subordinating schema
parts to other schema parts. Lastly, the design application 126 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.
[0111] The example set forth in FIG. 12 shows various types of
components and schema parts, but is not intended to limit the
abilities of the design application 126, the user interface 128, or
the system 100; other types of components and ways to present them
can be used.
[0112] A Computer System
[0113] FIG. 13 shows an exemplary computer system that can be used
to implement the processes described herein. Computer 1342 includes
one or more processors or processing units 1344, a system memory
1346, and a bus 1348 that couples various system components
including the system memory 1346 to processors 1344. The bus 1348
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. The system memory 1346 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 within
computer 1342, such as during start-up, is stored in ROM 1350.
[0114] Computer 1342 further includes a hard disk drive 1356 for
reading from and writing to a hard disk (not shown), a magnetic
disk drive 1358 for reading from and writing to a removable
magnetic disk 1360, and an optical disk drive 1362 for reading from
or writing to a removable optical disk 1364 such as a CD ROM or
other optical media. The hard disk drive 1356, magnetic disk drive
1358, and optical disk drive 1362 are connected to the bus 1348 by
an SCSI interface 1366 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 for computer 1342.
Although the exemplary environment described herein employs a hard
disk, a removable magnetic disk 1360 and a removable optical disk
1364, 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.
[0115] A number of program modules may be stored on the hard disk
1356, magnetic disk 1360, optical disk 1364, ROM 1350, or RAM 1352,
including an operating system 1370, one or more application
programs 1372 (such as a design application), other program modules
1374, and program data 1376. A user may enter commands and
information into computer 1342 through input devices such as a
keyboard 1378 and a pointing device 1380. 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 the processing unit 1344 through an interface 1382
that is coupled to the bus 1348. A monitor 1384 or other type of
display device is also connected to the bus 1348 via an interface,
such as a video adapter 1386. In addition to the monitor, personal
computers typically include other peripheral output devices (not
shown) such as speakers and printers.
[0116] Computer 1342 commonly operates in a networked environment
using logical connections to one or more remote computers, such as
a remote computer 1388. The remote computer 1388 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 to computer 1342. The logical
connections depicted in FIG. 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.
[0117] When used in a LAN networking environment, computer 1342 is
connected to the local network through a network interface or
adapter 1394. When used in a WAN networking environment, computer
1342 typically includes a modem 1396 or other means for
establishing communications over the wide area network 1392, such
as the Internet. The modem 1396, which may be internal or external,
is connected to the bus 1348 via a serial port interface 1368. In a
networked environment, program modules depicted relative to the
personal computer 1342, 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.
[0118] Generally, the data processors of computer 1342 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.
[0119] 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
[0120] 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.
* * * * *
References