Patent Publication Number: US-6342907-B1

Title: Specification language for defining user interface panels that are platform-independent

Description:
REFERENCE TO MICROFICHE APPENDIX 
     A single microfiche appendix that contains a total of 43 frames is included with this patent application. 
     BACKGROUND OF THE INVENTION 
     1. Technical Field 
     This invention generally relates to computer system displays and more specifically relates to a mechanism and method for defining and displaying user interface panels that are platform-independent. 
     2. Background Art 
     The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices that may be found in many different settings. Computer systems typically include a combination of hardware (e.g., semiconductors, circuit boards, etc.) and software (e.g., computer programs). As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago. 
     Early computer systems used command-based operating systems and software applications. These command-based systems provided a user interface that required the user to memorize a relatively large number of commands in order to perform meaningful work. The user interfaces for these command-driven computer programs required a relatively high level of skill to operate, and were not considered to be “user-friendly.” With the introduction of the IBM personal computer (PC), computers became more widely available, both in the workplace and in homes, and the computer industry soon recognized the need to provide more user-friendly interfaces to computer programs. As a result, many different operating systems were introduced that provided a graphical user interface (GUI), including IBM&#39;s OS/2, Microsoft Windows, and the Apple McIntosh. Software applications with graphical user interfaces soon followed, and the vast majority of computer programs running on personal computers today provides a user-friendly graphical user interface. 
     Most graphical user interfaces provide many common features. The basic display area in a graphical user interface is known as a window or panel. For the discussion in this patent application, we refer to a basic display area as a panel, recognizing that other terms are known in the art to describe display areas. A single panel may fill the entire display, or the display can be split into a number of different panels. A panel may include a number of different “components”, which are different areas that display text, drop-down lists, text entry fields, etc. A pointing device such as a trackball or a mouse is generally used to select various commands and options on a panel by clicking on the appropriate fields or buttons within the panel. In addition, a keyboard is commonly used to enter text information into a panel. 
     Various methods have been developed for generating panels. For example, an editor provided with Microsoft Visual C++ provides a graphical tool that allows a programmer to define a panel that may be displayed using Microsoft Windows by selecting and dropping desired components onto the panel. When the programmer is finished, the panel is defined as a Windows resource script (.rc file). Resource script is a special programming language that allows a user to define the appearance and function of a panel. Of course, when a programmer uses a graphical tool to generate a panel, the tool translates the components the programmer sees on the panel into a corresponding resource script without the programmer directly writing code in resource script format. An example of a panel defined in Windows resource script is shown in FIG. 3, with the corresponding resource script shown in FIGS. 4A and 4B. 
     While generating panels using Visual C++ is relatively straightforward, the resulting panels in resource script format can only be displayed on a Microsoft Windows platform. Today, there is a great push to provide software applications that are “platform-independent”, which means that a software application may run on computer systems that have different operating systems, such as OS/2, Windows, AIX, AS/400, etc. The Java programming language developed by Sun Microsystems provides a programming language for platform-independent software applications. 
     The Java programming language currently has some graphical tools for generating panels in Java, such as Symantec Visual Cafe. These graphical tools generate Java code, and define sizes and positions of user interface components in absolute pixel coordinates. However, the preferred method of generating user interface panels in Java uses Java-defined classes known as layout managers. Java allows a programmer to select an appropriate layout manager class depending on the type of panel that the programmer wants to display and then add appropriate components to the panel. The layout manager will then work out how the components are displayed in the panel. It is often necessary to use different layout managers for different sections of a panel, imposing upon the programmer the burden and complexity of dealing with multiple layout managers. 
     Typically, the functional components are distinguished from mere text or other display information that is simply displayed to a user. The text or other display information is typically stored in a resource bundle separate from the Java functional components. Thus, a panel with English text will have a corresponding English resource bundle, while the same panel could be displayed in German using a German resource bundle instead of the English resource bundle. An example of a user interface panel that was generated in Java and that uses an English resource bundle is shown in FIG.  5 . 
     In Java, the programmer has no direct control of location of components within the panel. The logic behind the layout managers is to allow an application to be ported to a different language quickly and easily. Thus, if the text on a button is twice as long in German than it is in English, the layout manager has the intelligence to stretch the button to accommodate the longer German label (stored in the German resource bundle) on the button. The panel of FIG. 6 is a German version of the panel of FIG.  5 . However, defining user interface panels in Java has significant drawbacks. The programmer has no precise control over the appearance of components on a panel, but must instead rely on a Java layout manager to determine the size and position of components on the panel. In addition, using the layout managers in Java to generate a user interface panel requires that the programmer is skilled in the Java programming language. Thus, the generation and modification of user interface panels must be performed by a skilled Java programmer. This is in stark contrast to the Windows environment, where a person can design a platform-specific user interface panel using a graphical editor, having no specialized programming knowledge. Even using the graphical editors for Java panels, such as Symantec Visual Cafe, the result is Java code that defines sizes and positions of user interface components in absolute pixel coordinates, and that bypass the Java layout managers. This makes it difficult to port the panels to a different language, because translators must create new versions of the generated Java code for each language, and the application is obliged to provide run-time code that figures out which version of the panel should be invoked based on the language/country settings currently in effect. Without a mechanism that gives the programmer precise control over the location of components on a platform-independent panel without requiring specialized programming skills, the generation of platform-independent user interface panels will continue to be an impediment to the generation of platform-independent software. 
     DISCLOSURE OF INVENTION 
     According to the preferred embodiments, a specification language allows a user to define platform-independent user interface panels without detailed knowledge of complex computer programming languages. The specification language is referred to herein as a Panel Definition Markup Language (PDML), which defines tags that are used in similar fashion to those defined in Hypertext Markup Language (HTML), that allow a user to specify the exact location of components displayed in the panel. A graphical editor allows the creation and modification of platform-independent user interface panels without programming directly in the specification language. A conversion tool may be used to convert platform-specific user interface panels to corresponding platform-independent user interface panels. A help generator tool also facilitates the generation of context-sensitive help for a user interface panel. 
     The foregoing and other features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings. 
    
    
     BRIEF DESCRIPTION OF DRAWINGS 
     The preferred embodiments of the present invention will hereinafter be described in conjunction with the appended drawings, where like designations denote like elements, and: 
     FIG. 1 is a block diagram of an apparatus in accordance with a preferred embodiment of the present invention; 
     FIG. 2 is a block diagram of some of the classes that represent the run-time managers  126  of FIG. 1; 
     FIG. 3 is a display of a user interface panel defined using an editor for generating a Windows panel, such as that provided by Microsoft Visual C++; 
     FIGS. 4A-4B show the Windows resource script for the panel of FIG. 3; 
     FIG. 5 is a display of a user interface panel defined using a layout manager in Java when the panel is displayed in English; 
     FIG. 6 is a display of the user interface panel of FIG. 5 when the panel is displayed in German; 
     FIG. 7 is a flow diagram of a method in accordance with the preferred embodiments; 
     FIGS. 8A-8E show an XML Document Type Definition file that defines the Panel Definition Markup Language (PDML) in accordance with the preferred embodiments; 
     FIG. 9 shows some of the components defined in PDML; 
     FIG. 10 is a block diagram of a framework and associated items that process and display PDML panels; 
     FIG. 11 is a display of the user interface panel in FIG. 3 when defined using PDML; 
     FIGS. 12A-12E show the PDML code for the panel of FIG. 11; 
     FIG. 13 is a block diagram showing the conversion of a Windows resource script file to a PDML file by the panel conversion tool of FIG. 1; 
     FIG. 14 displays the HTML output of the help generator tool of FIG. 1 that aids a programmer to develop context-sensitive help for a display panel; and 
     FIG. 15 displays a more detailed HTML help skeleton that is displayed when the Text Area link of FIG. 14 is selected. 
    
    
     BEST MODE FOR CARRYING OUT THE INVENTION 
     The present invention is accomplished through the generation of user interface panels in a platform-independent object oriented programming language, such as Java. For those who are not familiar with object oriented programming concepts or the Java programming language, the brief overview below provides background information that will help the reader to understand the present invention. 
     1. Overview 
     Object Oriented Technology v. Procedural Technology 
     Object oriented programming is a method of program implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships. Object oriented programming differs from standard procedural programming in that it uses objects, not algorithms, as the fundamental building blocks for creating computer programs. This difference stems from the fact that the design focus of object oriented programming technology is wholly different than that of procedural programming technology. 
     The focus of procedural-based design is on the overall process used to solve the problem; whereas the focus of object oriented design is on casting the problem as a set of autonomous entities that can work together to provide a solution. The autonomous entities of object oriented technology are, of course, objects. Object oriented technology is significantly different from procedural technology because problems are broken down into sets of cooperating objects instead of into hierarchies of nested computer programs or procedures. 
     Thus, a pure object oriented program is made up of code entities called objects. Each object is an identifiable, encapsulated piece of code and data that provides one or more services when requested by a client. Conceptually, an object has two parts, an external object interface and internal object implementation. In particular, all object implementation functions are encapsulated by the object interface such that other objects must communicate with that object through its object interface. The only way to retrieve, process or otherwise operate on the object is through the methods defined on the object. This protects the internal data portion of the object from outside tampering. Additionally, because outside objects have no access to the internal implementation, that internal implementation can change without affecting other aspects of the program. 
     In this way, the object system isolates the requestor of services (client objects) from the providers of services (server objects) by a well defined encapsulating interface. In the classic object model, a client object sends request messages to server objects to perform any necessary or desired function. The message identifies a specific method to be performed by the server object, and also supplies any required parameters. The server object receives and interprets the message, and can then decide what operations to perform. 
     There are many computer languages that presently support object oriented programming techniques. For example, Smalltalk, Object Pascal, C++ and Java are all examples of programming languages that support object oriented programming to one degree or another. 
     Java Programing Language 
     Java is a modern object oriented programming language designed by Sun Microsystems that has grown in popularity in recent years. Java offers many features and advantages that makes it a desirable programming language to use. First, Java is specifically designed to create small application programs, commonly called “applets,” that can reside on the network in centralized servers, and which are delivered to the client machine only when needed. Second, Java is completely platform independent. A Java program can be written once and can then run on any type of platform that contains a Java Virtual Machine (JVM). The JVM model is supported by most computer vendors, thereby allowing a software vendor to have access to hardware and software systems produced by many different companies. Finally, Java is an object oriented language, meaning that software written in Java can take advantage of the benefits of object oriented programming techniques. 
     As in other object oriented systems, operations in Java are performed by one object calling a method on another object. These objects can reside locally on the same machine or on separate JVM&#39;s physically located on separate computers or systems. 
     2. Detailed Description 
     According to a preferred embodiment of the present invention, a panel definition markup language (PDML) is defined in extensible markup language (XML) that provides a way to define user interface panels in a platform-independent manner while giving the programmer precise control over the placement of components on the panel. This allows a programmer to define user interface panels using a relatively simple markup language, rather than by programming in C++ or another relatively complex object oriented programming language. 
     Referring to FIG. 1, a computer system  100  in accordance with the preferred embodiment is an enhanced IBM RS/6000 computer system. However, those skilled in the art will appreciate that the mechanisms and apparatus of the present invention apply equally to any computer system, regardless of whether the computer system is a complicated multi-user computing apparatus or a single user workstation. As shown in FIG. 1, computer system  100  comprises a processor  110  connected to a main memory  120 , a mass storage interface  130 , a display interface  140 , and a network interface  150 . These system components are interconnected through the use of a system bus  160 . Mass storage interface  130  is used to connect mass storage devices (such as a direct access storage device  155 ) to computer system  100 . One specific type of direct access storage device is a floppy disk drive, which may store data to and read data from a floppy diskette  195 . 
     Main memory  120  in accordance with the preferred embodiments contains data  121 , an operating system  122 , an XML definition  123  of a panel definition markup language (PDML), one or more panels  124  defined in PDML, a resource bundle  125 , one or more run-time managers  126 , a graphical user interface (GUI) panel builder  127 , a panel conversion tool  128 , and a help generator tool  129 . Computer system  100  utilizes well known virtual addressing mechanisms that allow the programs of computer system  100  to behave as if they only have access to a large, single storage entity instead of access to multiple, smaller storage entities such as main memory  120  and DASD device  155 . Therefore, while data  121 , operating system  122 , XML definition  123  of PDML, PDML panels  124 , resource bundle  125 , run-time managers  126 , GUI panel builder  127 , panel conversion tool  128 , and help generator tool  129  are shown to reside in main memory  120 , those skilled in the art will recognize that these items are not necessarily all completely contained in main memory  120  at the same time. It should also be noted that the term “memory” is used herein to generically refer to the entire virtual memory of computer system  100 . 
     Data  121  represents any data that serves as input to or output from any program in computer system  100 . Operating system  122  is a multitasking operating system known in the industry as AIX; however, those skilled in the art will appreciate that the spirit and scope of the present invention is not limited to any one operating system. Operating system  122  preferably supports an object oriented programming environment such as that provided, for example, by the Java programming language. 
     XML definition  123  of PDML is a file in extensible markup language (XML) format that defines the tags that are used in PDML. XML is a very flexible and powerful way to define a markup language. One example of a well-known markup language is hypertext markup language (HTML) that is used to display web pages on the Internet. XML defines a grammar for creating your own markup language. It provides a way to define a set of tags, similar to HTML tags, and to specify the order in which the tags may occur and what tags may enclose other tags. 
     XML definition  123  of PDML defines the features of PDML that allow a programmer to define a panel and components on the panel. The XML definition  123  of PDML is thus one specific example of a suitable specification language in accordance with a preferred embodiment for defining platform-independent user interface panels. XML is an evolving industry standard defined by the World Wide Web Consortium, commonly known as W 3 C. It is a subset of the Standard Generalized Markup Language (SGML) which is targeted for use on the Web. A copy of the XML specification dated Dec. 8, 1997 is included as a microfiche appendix. XML is platform-independent, and therefore panels that are defined using PDML, which is defined in XML, are also platform-independent. 
     An XML document may be parsed, or dissected into its constituent parts, for use by Java applications. The W 3 C defines certain standards to which XML parser software must be written, and there are a number of XML parsers available for free on the world-wide web. For example, a suitable XML parser is the IBM XML For Java parser which is available from IBM&#39;s Yamato research lab. 
     Each PDML panel  124  is a panel that is defined by a programmer using the tags and syntax that defines the panel definition markup language (PDML). Each panel may have one or more components, as discussed in more detail below. Resource bundle  125  is a language-specific bundle of information that may be used by a panel to display its various components. For example, a resource bundle  125  may be provided in English to display text on a panel in English. A different resource bundle  125  may be provided to display the same panel in German. The resource bundle makes it relatively easy to port user interface panels to different languages. 
     Run-time managers  126  process PDML panels  124  and resource bundles  125  to generate a displayed panel. In the preferred embodiment, run-time managers  126  are defined using a set of Java classes in a Java class library  200 , as shown in FIG.  2 . Java class library  200  is a collection of Java classes that are needed to support the processing and display of PDML panels  124 . Java class library  200  suitably includes a panel manager class  210 , a property sheet manager class  220 , a wizard manager class  230 , a split pane manager class  240 , a deck pane manager class  250 , a tabbed pane manager class  260 , a look and feel manager class  270 , and Java foundation classes  280 . The panel manager, property sheet manager, and wizard manager are discussed in more detail below, along with a description of some of the relevant Java foundation classes  280  that are needed to process and display PDML panels. 
     Referring back to FIG. 1, GUI panel builder  127  is a tool that provides a graphical user interface for defining panels in PDML. In the preferred embodiment, GUI panel builder  127  is a what-you-see-is-what-you-get (WYSIWYG) editor similar to the editor in Microsoft Visual C++ that allows graphic building of panels for a Windows environment. The big difference, of course, is that the PDML panels  124  defined using GUI panel builder  127  are platform-independent. GUI panel builder  127  eliminates the need for a person that wants to define user interface panels to learn a complex object oriented programming language such as C++ or Java, and even eliminates the need for the person to learn PDML. GUI panel builder  127  provides a graphical interface and translates the graphical components automatically into PDML. 
     Panel conversion tool  128  allows for automatically converting a platform-specific user interface panel to an equivalent PDML representation of the panel. For example, a specific example of panel conversion tool  128  may convert Windows resource script (.rc) files to an equivalent PDML representation of the panel. Panel conversion tool  128  thus provides a programmer a very simple way to convert platform-specific panels to PDML, which is platform-independent. Needless to say, panel conversion tool  128  can greatly speed porting a platform-specific user interface panel to Java or any other platform independent representation of that panel. 
     Help generator tool  129  is a tool that helps a programmer generate context sensitive help for a PDML panel. Help generator tool  129  defines a “help skeleton” with headings that correspond to components on the PDML panel. A programmer can then add text or other features to the help skeleton to generate one or more help screens that corresponds to a user interface panel  124  defined in PDML. 
     Processor  110  may be constructed from one or more microprocessors and/or integrated circuits. Processor  110  executes program instructions stored in main memory  120 . Main memory  120  stores programs and data that processor  110  may access. When computer system  100  starts up, processor  110  initially executes the program instructions that make up operating system  122 . Operating system  122  is a sophisticated program that manages the resources of computer system  100 . Some of these resources are processor  110 , main memory  120 , mass storage interface  130 , display interface  140 , network interface  150 , and system bus  160 . 
     Although computer system  100  is shown to contain only a single processor and a single system bus, those skilled in the art will appreciate that the present invention may be practiced using a computer system that has multiple processors and/or multiple buses. In addition, the interfaces that are used in the preferred embodiment each include separate, fully programmed microprocessors that are used to off-load compute-intensive processing from processor  110 . However, those skilled in the art will appreciate that the present invention applies equally to computer systems that simply use I/O adapters to perform similar functions. 
     Display interface  140  is used to directly connect one or more displays  165  to computer system  100 . These displays  165  are used to display information to system administrators and users. Note, however, that while display interface  140  is provided to support communication with one or more displays  165 , computer system  100  does not necessarily require a local display  165 , because all needed interaction with users and other processes may occur via network interface  150  to displays on remote workstations. 
     Network interface  150  is used to connect other computer systems and/or workstations (e.g.,  175  in FIG. 1) to computer system  100  across a network  170 . The present invention applies equally no matter how computer system  100  may be connected to other computer systems and/or workstations, regardless of whether the network connection  170  is made using present-day analog and/or digital techniques or via some networking mechanism of the future. In addition, many different network protocols can be used to implement a network. These protocols are specialized computer programs that allow computers to communicate across network  170 . TCP/IP (Transmission Control Protocol/Internet Protocol) is an example of a suitable network protocol. 
     It is also important to point out that the presence of network interface  150  within computer system  100  means that computer system  100  may engage in cooperative processing with one or more other computer systems or workstations on network  170 . Of course, this in turn means that the programs and data shown in main memory  120  need not necessarily all reside on computer system  100 . For example, one or more portions shown in main memory  120  may reside on another system and engage in cooperative processing with one or more objects or programs that reside on computer system  100 . This cooperative processing could be accomplished through use of one of the well known client-server mechanisms such as remote procedure call (RPC). 
     At this point, it is important to note that while the present invention has been and will continue to be described in the context of a fully functional computer system, those skilled in the art will appreciate that the present invention is capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of suitable signal bearing media include: recordable type media such as floppy disks (e.g.,  195  of FIG. 1) and CD ROM, and transmission type media such as digital and analog communications links. 
     Referring now to FIG. 7, a method  700  for generating and displaying PDML panels in accordance with the preferred embodiments includes the steps of defining the PDML language using XML (step  710 ); generating one or more panels as files in PDML (step  720 ); and processing the PDML files (that correspond to panels) to display the panels to a user (step  730 ). The definition of PDML in XML (step  710 ) is performed by supplying a Document Type Definition file to XML that defines the tags and other parameters for PDML. A suitable example of a Document Type Definition file that defines PDML in accordance with a preferred embodiment is shown in FIGS. 8A-8E. 
     Some of the tags defined in PDML that correspond to graphical components in a panel are shown in FIG.  9 . These tags are used to define a panel (using the PANEL tag), and are also used to define the components in a panel (such as label, image, button, etc.). These tags are used in a syntax that is similar to the syntax for hypertext markup language (HTML) that is commonly used to generate and display web pages. Providing tags in PDML thus provides an interface that an experienced HTML programmer will be able to learn and apply very quickly. The tags in FIG. 9 are described in more detail below. 
     The use of an XML-based tag language such as PDML has many benefits. Developers have precise control over the sizes and positions of user interface components. Changes to the panel layout do not require any code to be recompiled. Unique versions of a given panel may easily be created for each national language supported by an application. Translators do not need specialized skills in an object oriented programming language to modify the panel definitions. 
     Associated with the PDML representation of user interface panels is a pure Java runtime framework that interprets the PDML and constructs the panels, using user interface components in the Java Foundation Class library (JFC). FIG. 10 illustrates the elements and flow through the user interface framework  1000 . The user interface framework  1000  interprets PDML data that is obtained by either parsing a PDML document using XML parser  1010 , or by loading a serialized panel definition  1030 , which is a pre-parsed panel definition. Several run-time managers  126  are provided that dictate how the PDML data is displayed on displayed panel  1090 . One of the run-time managers is a Java LayoutManager implementation  1020  that supports panel layouts defined using either Windows Dialog Logical Units (DLUs) or pixels. Pixel-based screens are scaled to the current screen size, using the screen resolution on which the panel was originally developed as a base. The panel manager  1021  is a run-time manager class that defines dialogs (modal and modeless), and online help information. The property sheet manager  1022  is a run-time manager class that determines how property sheets and property pages are displayed. The wizard run-time manager class  1023  determines how wizards and wizard pages are displayed. The split pane run-time manager class  1024  determines how aggregate panels are displayed using split panes. The deck pane run-time manager class  1025  determines how aggregate panels are displayed using a deck pane, which has several panes one atop the other like a deck of cards. The tabbed pane run-time manager class  1026  determines how aggregate panels are displayed in a tabbed pane. The look and feel run-time manager class  1027  determines the look and feel of the graphical user interface. Look and feel management is accomplished at runtime via the Pluggable Look and Feel (PLAF) manager in the Java Foundation Class library, which makes Windows looks like Windows and which makes AIX look like AIX. The default look and feel is the “metal” look and feel that is defined in the Java foundation classes, which doesn&#39;t correspond to a particular platform. These run-time managers  126  collectively determine the appearance of the displayed panel  1090  that results from processing a PDML file using framework  1000 . 
     Framework  1000  also includes a common data exchanger class  1040  that handles the exchange of data between the user interface components and one or more Java data beans  1080  defined by the application, via method introspection on the data bean. In addition, common formatter classes  1050  and common handlers  1060  provide for data formatting, handling and validation that are specified in the PDML. In addition, custom handlers  1070  are provided that customize the function of displayed panel  1090  and can be extended. One example of suitable custom handlers  1070  include user interface component level event listeners that are specified in the PDML and can be extended. These listeners monitor (i.e., listen) for certain events to occur, and act on the occurrence of those events. The user interface framework  1000  of FIG. 10 provides a productive development environment for building user interface panels in PDML. The framework  1000  automatically handles the exchange of data, and the developer need only create one or more Data Beans and bind them to the panel components using tags in PDML. For enhanced capabilities, the developer may also specify one or more custom handlers  1070  that customize the function of displayed panel  1090 . 
     Note that framework  1000  can be executed in a web browser, with the run-time managers  126  residing on a web server in archived form. In this scenario, when a user links to a web page that incorporates a Java applet developed using the PDML framework, the archived class library is downloaded to the web client, and all parsing and rendering is performed in the browser&#39;s execution space. 
     Panel Definition Markup Language thus defines an XML vocabulary for specifying the layout of user interface panels. This vocabulary is intended to be independent of both the user interface platform and the user interface implementation technology. The XML elements which make up the Panel Definition Markup Language are order-dependent, and are preferably specified in the order described herein. Names of PDML elements and attributes are case sensitive, but predefined character data and attribute values are not. The gettor and settor methods defined for each user interface component need not be implemented for the panel to function correctly. The user interface framework will write an informational message to the console for each method it was unable to locate, but the panel will still display normally. This allows developers to test the appearance of a panel without having to implement the associated data retrieval/storage mechanisms. In addition, a developer may not wish to provide the function associated with a particular access method. For example, it may not be desirable to allow users to update certain fields, in which case the settor methods might never be implemented for those fields. 
     PDML Tags 
     XML is used to specify many tags that provide the desired functionality of PDML. These tags are described in detail below. 
     PDML Root Element 
     Every XML vocabulary defines a root element which cannot be enclosed by any other elements. The root element for PDML is specified as follows: 
     &lt;PDML version=version source=platform basescreensize=screensize&gt; 
     In the version argument, the version of PDML used in this document is specified (such as 1.0). The platform argument specifies the platform on which the panels were originally defined, such as Windows or Java. If Windows is specified, the XML is assumed to have been generated by the panel conversion tool  128 , and the logical panel coordinates contained in the PDML will be interpreted as Windows Dialog Logical Units (DLUs). If Java is specified, the PDML is assumed to have been generated by the GUI panel builder  127 , or to have been created manually. When Java is specified, the logical panel coordinates contained in the PDML will be interpreted as pixels, which are the base units employed by the Java Foundation Classes. Of course, support for other platforms may be added as required by specifying other allowable possibilities for the platform argument. The basescreensize argument specifies the dimensions in pixels of the device on which the panels were originally defined. The basescreensize is specified as a width and a height, for example “1024×768”. An end tag is required, and it must be the last element in the XML document. 
     PANEL Tag 
     One or more panels may be defined within the scope of a root PDML element. This is done using the PANEL tag: 
     &lt;PANEL name=name&gt; 
     where name is the text string which will be used to identify the panel programmatically. The panel name must be unique within the scope of a given PDML document. Within the scope of the PANEL tag, the TITLE, SIZE, ICON, and ACTIVATE tags (described below) may be specified. 
     TITLE Tag 
     &lt;TITLE&gt;title&lt;/TITLE&gt; 
     The TITLE tag defines the text string that will be displayed in the title bar of the panel. An attempt will be made to load the string from the resource bundle associated with the panel definition, using title as the key. If the string is not found, the title string as it appears in the PDML will be displayed. The TITLE tag is required. 
     SIZE Tag 
     &lt;SIZE&gt;size&lt;/SIZE&gt; 
     The SIZE tag defines the size of the panel in logical units, where size is expressed as a pair of integers “width,height”. The SIZE tag is required. 
     ICON Tag 
     &lt;ICON&gt;icon&lt;/ICON&gt; 
     The ICON tag defines the resource key of the filename string in the panel&#39;s resource bundle that identifies the binary file containing the image to be used as the icon for the panel. This tag is optional; if omitted, the standard Java window icon will be used. 
     ACTIVATE Tag 
     &lt;ACTIVATE&gt;class_name&lt;/ACTIVATE&gt; 
     The ACTIVATE tag defines the fully qualified name of a handler class  1070  that will receive control when the panel is initially displayed. The framework will automatically create an object of the specified class, and notify the object when the panel is activated. This tag is optional. 
     Any number of user interface components may also be specified within the scope of the PANEL tag. These tags are described below. The names assigned to the components must be unique within the scope of a given panel definition. 
     Disabled Attribute 
     Many of the user interface panel components discussed below specify an attribute ‘disabled=“yes|no”’. The disabled attribute allows the programmer to request that the user interface component be initially displayed in a “disabled state”, i.e. grayed out with user input disabled. The disabled attributes applies to many of the tags described below. 
     LABEL Tag 
     The LABEL tag creates a static text component of the specified size and location on the panel. 
     &lt;LABEL name=name disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the label programmatically. Within the scope of the LABEL tag, the TITLE and SIZE flags described above may be specified, along with the LOCATION, FLYOVER, and HELPALIAS tags, described below. 
     LOCATION Tag 
     &lt;LOCATION&gt;location&lt;/LOCATION&gt; 
     The location tag defines the location of the label in logical units, where location is expressed as a pair of integers x-coordinate,y-coordinate. The panel&#39;s origin is the top left comer of the panel. This tag is required. 
     FLYOVER Tag 
     &lt;FLYOVER&gt;helptext&lt;/FLYOVER&gt; 
     The FLYOVER tag defines the hover help text that will be displayed over the label. An attempt will be made to load the string from the resource bundle associated with the panel definition, using helptext as the key. If the string is not found, the helptext string as it appears in the PDML will be displayed. This tag is optional. 
     HELPALIAS Tag 
     &lt;HELPALIAS&gt;component_name&lt;/HELPALIAS&gt; 
     The name of the user interface component whose help topic should be displayed when context help is requested for this component. This tag is optional. 
     IMAGE Tag 
     The IMAGE tag displays an image at the specified location on the panel. 
     &lt;IMAGE name=name&gt; 
     where name is the text string which will be used to identify the image programmatically. Within the scope of the IMAGE tag, the TITLE, LOCATION, SIZE, and FLYOVER tags that relate to the image to be displayed may be specified, as described above. Note that the application may define action handlers (e.g.,  1070  in FIG. 10) for displaying a sequence of images at the location specified, effectively providing animation. 
     CUSTOM Tag 
     The CUSTOM tag adds a user-defined user interface component to the panel at the specified location. 
     &lt;CUSTOM name=name&gt; 
     where name is the text string that will be used to identify the component programmatically. Within the scope of the CUSTOM tag, the LOCATION and SIZE tags discussed above may be specified, as well as a MANAGERCLASS tag, described below. 
     MANAGERCLASS Tag 
     &lt;MANAGERCLASS&gt;class_name&lt;/MANAGERCLASS&gt; 
     The MANAGERCLASS tag defines the fully qualified class name of a handler class  1070  that will manage the component on behalf of the user interface framework. This tag is required. The user interface framework will delegate creation of the component and management of its data to an instance of the specified handler class. 
     BUTTON Tag 
     The BUTTON tag creates a pushbutton of the specified size and location on the panel. 
     &lt;BUTTON name=game disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the button programmatically. Within the scope of the BUTTON tag, the TITLE, LOCATION, SIZE, FLYOVER, and HELPALIAS tags discussed above may be specified. In addition, the STYLE and ACTION tags may be specified for the button, as described below. 
     STYLE Tag 
     &lt;STYLE&gt;style&lt;/STYLE&gt; 
     The STYLE tag defines a predefined style constant which controls the appearance of the button. The style argument may have a value of DEFAULT, which indicates that the button should receive the default emphasis, and indicates that the button&#39;s action should be invoked if the user presses the Enter key. This tag is optional. 
     ACTION Tag 
     &lt;ACTION&gt;action&lt;/ACTION&gt; 
     The ACTION tag defines a predefined action constant which specifies the action to be taken when the user clicks the button. The action argument may have the value of COMMIT, CANCEL, or HELP. If the action argument is COMMIT, all pending changes to the data on the panel will be applied to the appropriate data objects, the changes will then be committed by calling the save method on the data objects, and the panel window will close. If the action argument is CANCEL, the panel window will close without saving any of the user&#39;s changes. If the action argument is HELP, a help browser window containing the overview help for the panel will be displayed. Alternatively, action may specify the fully qualified name of a handler class  1070  that will receive control when the button is clicked. The framework will automatically create an object of the specified class, and notify the object when the button is clicked. This tag is optional. 
     GROUPBOX Tag 
     The GROUPBOX tag creates a labeled box of the specified size and location on the panel. 
     &lt;GROUPBOX name=name&gt; 
     where name is the text string which will be used to identify the group box programmatically. Within the scope of the GROUPBOX tag, the TITLE, LOCATION, SIZE, and HELPALIAS tags discussed above may be specified. 
     RADIOBUTTON Tag 
     The RADIOBUTTON tag creates a radio button of the specified size and location on the panel. 
     &lt;RADIOBUTTON name=name disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the radio button programmatically. Within the scope of the RADIOBUTTON tag, the TITLE, LOCATION, SIZE, FLYOVER, and HELPALIAS tags described above may be specified, as well as the DATACLASS, ATTRIBUTE, SELECTED, and DESELECTED tags described below. 
     DATACLASS Tag 
     &lt;DATACLASS&gt;class_name&lt;/DATACLASS&gt; 
     The DATACLASS tag defines the fully qualified class name of the data object which supplies the state of the radio button. An instance of this class is supplied to the class library by the application. This tag is optional. 
     ATTRIBUTE Tag 
     &lt;ATTRIBUTE&gt;attribute_name&lt;/ATTRIBUTE&gt; 
     The ATTRIBUTE tag defines the property of the data object that contains the state of the radio button. This tag is optional, but must be present if the DATACLASS tag is specified. The gettor protocol for the ATTRIBUTE tag is a boolean is&lt;attribute_name&gt;( ), where the return value indicates whether the radio button is selected. The settor protocol for the ATTRIBUTE tag is a boolean set&lt;attribute_name&gt;(boolean selected), where “selected” indicates whether the radio button is selected. 
     SELECTED/DESELECTED Tags 
     The panel designer may elect to have certain actions performed when the radio button is selected, deselected, or both. Within the scope of the SELECTED tag, for example, the following tags may be specified: 
     &lt;ENABLE&gt;component_list&lt;/ENABLE&gt; 
     &lt;DISABLE&gt;component_list&lt;/DISABLE&gt; 
     &lt;SHOW&gt;component_list&lt;/SHOW&gt; 
     &lt;HIDE&gt;component_list&lt;/HIDE&gt; 
     &lt;REFRESH&gt;component_list&lt;/REFRESH&gt; 
     &lt;DISPLAY&gt;pane_list&lt;/DISPLAY&gt; 
     where component_list is a comma-separated list of user interface component identifiers. A component identifier is a string identifier of the form panel_name.component_name where panel_name is the name of the panel in which the component is defined, and component_name is the name of the component itself. If the target component is defined within the same panel as the radio button, the identifier need not be qualified with the panel name. 
     Pane_list is a comma-separated list of window pane identifiers. A window pane identifier is a string of the form subpanel_name.panel_name where subpanel_name is the name of the aggregate subpanel in which the panel resides, and panel_name is the name of the panel itself. An aggregate subpanel is a type of container which is capable of displaying multiple panels, such as a tabbed window control or a splitter window. If the target panel resides within the same aggregate subpanel as the radio button, the identifier need not be qualified with the subpanel name. 
     The following actions will be performed based on the tags specified. 
     ENABLE—The target component(s) will be enabled for user input. 
     DISABLE—The target component(s) will be disabled for user input. 
     SHOW—The target component(s) will be displayed on the panel. 
     HIDE—The target component(s) will be hidden from view. 
     REFRESH—The target component(s) will have their data refreshed. Changes made by the user will be applied, but not committed, before the refresh occurs. 
     DISPLAY—The target subpanel(s) will display the specified pane(s). 
     The use of these tags in conjunction with the SELECTED and DESELECTED tags allows the panel designer to define the desired user interface behavior without actually having to write any Java code. 
     CHECKBOX Tag 
     The CHECKBOX tag creates a check box of the specified size and location on the panel. 
     &lt;CHECKBOX name=name disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the check box programmatically. Within the scope of the CHECKBOX tag, the TITLE, LOCATION, SIZE, DATACLASS, ATTRIBUTE, SELECTED, DESELECTED, FLYOVER, and HELPALIAS tags discussed above may be specified. 
     BUTTONGROUP Tag 
     The BUTTONGROUP tag defines a group of push buttons, radio buttons or check boxes, only one of which may be selected at a time. 
     &lt;BUTTONGROUP name=name disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the button group programmatically. Within the scope of the BUTTONGROUP tag, the DATACLASS and ATTRIBUTE tags may be specified. 
     COMBOBOX Tag 
     The COMBOBOX tag creates a dropdown list box of the specified size and location on the panel. If the combo box is defined as editable, the user may supply data in an editable text field in addition to choosing one of the choices shown in the dropdown list. 
     &lt;COMBOBOX name=name editable=“yes”|“no” disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the combo box programmatically. Within the scope of the COMBOBOX tag, the LOCATION, SIZE ATTRIBUTE, FLYOVER, and HELPALIAS tags discussed above may be specified. In addition, the CHOICE, SHORT, INTEGER, LONG, FLOAT, STRING, and FORMAT tags discussed below may be specified. 
     CHOICE Tag 
     If the strings to be inserted in a dropdown list are invariant, the choices may be specified using one or more CHOICE tags, as follows: 
     &lt;CHOICE name=name&gt; 
     where name is the text string which will be used to identify the choice programmatically. Within the scope of the CHOICE tag, the TITLE, ENABLE, DISABLE, SHOW, HIDE, REFRESH, and DISPLAY tags discussed above may be specified. If the choices in a dropdown list can vary dynamically at runtime, then no choices should be specified in the PDML. The framework will call the data object identified on the DATACLASS tag to obtain the list of choices. 
     SHORT Tag 
     One of the following optional tags may be specified when the combo box is defined as editable: 
     &lt;SHORT[minvalue=“value1”][maxvalue=“value2”]/&gt; 
     The SHORT tag specifies that the value in the text field must be a short integer that lies within the range value 1 -value 2 . Both the minvalue and maxvalue attributes are optional; if omitted, the value will be checked against the allowable range for short integers in Java. 
     INTEGER Tag 
     &lt;INTEGER[minvalue=“value1”][maxvalue=“value2”]/&gt; 
     The INTEGER tag specifies that the value in the text field must be an integer that lies within the range value 1 -value 2 . Both the minvalue and maxvalue attributes are optional; if omitted, the value will be checked against the allowable range for integers in Java. 
     LONG Tag 
     &lt;LONG[minvalue=“value1”][maxvalue=“value2”]/&gt; 
     The LONG tag specifies that the value in the text field must be a long integer that lies within the range value 1 -value 2 . Both the minvalue and maxvalue attributes are optional; if omitted, the value will be checked against the allowable range for long integers in Java. 
     FLOAT Tag 
     &lt;FLOAT [minvalue=“value1”] [maxvalue=“value2”]/&gt; 
     The FLOAT tag specifies that the value in the text field must be a floating point number which must lie within the range value1-value2. Both the minvalue and maxvalue attributes are optional; if omitted, the value will be checked against the allowable range for the double data type in Java. 
     STRING Tag 
     &lt;STRING [minlength=“value1”] [maxlength=“value2”]/&gt; 
     The STRING tag specifies that the value in the text field must be a string whose length is within the range value1-value2. Both the minlength and maxlength attributes are optional, but at least one must be specified. 
     FORMAT Tag 
     &lt;FORMAT&gt;format&lt;/FORMAT&gt; 
     The FORMAT tag defines a predefined format constant that specifies how the data in the text field should be interpreted when data is exchanged between a combo box component and its associated data object. The format argument may have one of the following values: PERCENT, DATE, TIME, and INTERNET ADDRESS, described below. 
     PERCENT—The data in the text field will be inspected to verify that it is a valid floating point value between 0.0 and 100.0. 
     DATE—The data in the text field will be inspected to verify that it contains a date that is formatted correctly for the current locale. 
     TIME—The data in the text field will be inspected to verify that it contains a time that is formatted correctly for the current locale. 
     INTERNET ADDRESS—The data in the text field will be inspected to verify that it is a valid dotted decimal address. If the data is found to be invalid according to the specified criteria, an appropriate error message will be displayed to the user. 
     Alternatively, the format argument may specify the fully qualified name of a handler class  1070  that will receive control when data is inserted into or extracted from a combo box. The framework will automatically create an object of the specified class, and call its format and parse methods to validate the data at the appropriate times. 
     TEXTFIELD Tag 
     The TEXTFIELD tag creates an editable text entry field of the specified size and location on the panel. 
     &lt;TEXTFIELD name=name disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the text field programmatically. Within the scope of the TEXTFIELD tag, the TITLE, LOCATION, SIZE, DATACLASS, ATTRIBUTE, SHORT, INTEGER, LONG, FLOAT, STRING, FORMAT, FLYOVER, and HELPALIAS tags discussed above may be specified. 
     TEXTAREA Tag 
     The TEXTAREA tag creates an editable multiline text entry field of the specified size and location on the panel. 
     &lt;TEXTAREA name=name disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the text area programmatically. Within the scope of the TEXTAREA tag, the TITLE, LOCATION, SIZE, DATACLASS, ATTRIBUTE, SHORT, INTEGER, LONG, FLOAT, STRING, FORMAT, FLYOVER, and HELPALIAS tags discussed above may be specified. 
     SLIDER Tag 
     The SLIDER tag creates an adjustable slider control of the specified size and location on the panel. The slider may be oriented horizontally or vertically. 
     &lt;SLIDER name=name orientation=“horizontal”|“vertical” disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the text area programmatically. Within the scope of the SLIDER tag, the LOCATION, SIZE, DATACLASS, ATTRIBUTE, FLYOVER, and HELPALIAS tags discussed above may be specified. In addition, MINVALUE, MAXVALUE, MAJORTICKS, MINORTICKS, and ADJUST tags discussed below may also be specified. 
     MINVALUE Tag &lt;MINVALUE&gt;value&lt;/MINVALUE&gt; 
     The MINVALUE tag defines a numeric constant which defines the lower bound of the slider. This tag is required. 
     MAXVALUE Tag 
     &lt;MAXVALUE&gt;value&lt;/MAXVALUE&gt; 
     The MAXVALUE tag defines a numeric constant that defines the upper bound of the slider. This tag is required. 
     MAJORTICKS Tag 
     &lt;MAJORTICKS&gt;interval&lt;/MAJORTICKS&gt; 
     The MAJORTICKS tag defines the interval at which labeled major ticks should be displayed, in slider units. This tag is optional; if omitted, no tick marks will be shown. Labels are in numeric slider units; custom labels are not supported. If this tag is present, snap-to-ticks is automatically set on. 
     MINORTICKS Tag 
     &lt;MINORTICKS&gt;interval&lt;/MINORTICKS&gt; 
     The MINORTICKS tag defines the interval at which unlabeled minor ticks should be displayed, in slider units. This tag is optional, but is required if MAJORTICKS is specified. 
     ADJUST Tag 
     &lt;ADJUST&gt;class_name&lt;/ADJUST&gt; 
     The ADJUST tag specifies the fully qualified name of a handler class  1070  that will receive control when the slider is adjusted. The framework will automatically create an object of the specified class, and notify the object whenever the slider is adjusted. This tag is optional. 
     PROGRESSBAR Tag 
     The PROGRESSBAR tag creates a progress indicator of the specified size and location on the panel. 
     &lt;PROGRESSBAR name=name&gt; 
     where name is the text string which will be used to identify the progress bar programmatically. Within the scope of the PROGRESSBAR tag, the LOCATION, SIZE, MINVALUE, MAXVALUE, FLYOVER, and HELPALIAS tags may be specified. The progress bar component does not exchange data with its associated data object at predefined times. Instead, changes to the progress bar are effected by a handler object  1070  associated with another component on the panel, or with the activation handler for the panel. 
     LIST Tag 
     The LIST tag creates a list box of the specified size and location on the panel. The selection mode of the list box may be defined as single selection, single interval selection (only one contiguous interval of list items may be selected at a time), or multiple interval (no restriction on which items may be selected). 
     &lt;LIST name=name selection=“single”|“singleinterval”|“multiinterval” disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the list box programmatically. Within the scope of the LIST tag, the LOCATION, SIZE, DATACLASS, ATTRIBUTE, SELECTED, DESELECTED, FLYOVER, and HELPALIAS tags discussed above may be specified. In addition, the ITEM and DOUBLECLICK tags defines below may also be specified. 
     ITEM Tag 
     If the strings to be inserted in the list box are invariant, the items may be specified using one or more ITEM tags, as follows: 
     &lt;ITEM name=name&gt; 
     where name is the text string which will be used to identify the item programmatically. Within the scope of the ITEM tag, the TITLE, ENABLE, DISABLE, SHOW, HIDE, REFRESH, and DISPLAY tags discussed above may be specified. 
     DOUBLECLICK Tag 
     &lt;DOUBLECLICK&gt;class_name&lt;/DOUBLECLICK&gt; 
     The DOUBLECLICK tag defines the fully qualified class name of a listener class that should be notified when the user double-clicks on an entry in the list. The framework will automatically create an object of the specified class, and notify the object when an entry in the list is double-clicked. This tag is optional. 
     TABLE Tag 
     The TABLE tag creates a multicolumn table of the specified size and location on the panel. The selection mode of the table may be defined as single selection, single interval selection (only one contiguous interval of table rows may be selected at a time), or multiple interval (no restriction on which rows may be selected). 
     &lt;TABLE name=name selection=“single”|“singleinterval”|“multiinterval” disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the table programmatically. Within the scope of the TABLE tag, the LOCATION, SIZE, SELECTED, DESELECTED, DOUBLECLICK, FLYOVER, and HELPALIAS tags discussed above may be specified. In addition, the COLUMN tag discussed below may also be specified. 
     COLUMN Tag 
     &lt;COLUMN&gt;&lt;/COLUMN&gt; 
     The columns that are to appear in the table are defined using the COLUMN tag. Columns may be defined as editable, which allows the user to enter data into any cell in the column. 
     &lt;COLUMN editable=“yes”|“no”&gt; 
     Within the scope of the COLUMN tag, the TITLE, DATACLASS, ATTRIBUTE, and ITEM, tags discussed above may be specified. In addition, a DEFAULTWIDTH tag described below may also be specified. These tags describe actions which will be performed when the table cell is selected. If the column items in the table can vary dynamically at runtime, then no items should be specified in the PDML. The framework will call the data object identified on the DATACLASS tag to obtain the column items. 
     DEFAULTWIDTH Tag 
     &lt;DEFAULTWIDTH&gt;width&lt;/DEFAULTWIDTH&gt; 
     The DEFAULTWIDTH tag defines the initial width of the column, in logical units. This tag is optional; if omitted, the columns will be displayed as having equal widths. 
     TREE Tag 
     The TREE tag displays a hierarchical tree of the specified size and location on the panel. 
     &lt;TREE name=name disabled=“yes|no”&gt; 
     where name is the text string which will be used to identify the tree programmatically. Within the scope of the TREE tag, the LOCATION, SIZE, DATACLASS, ATTRIBUTE, DOUBLECLICK, FLYOVER, and HELPALIAS tags discussed above may be specified. In addition, the ROOT/NODE and NODE tags discussed below may also be specified. 
     ROOT/NODE Tags 
     If the tree hierarchy is invariant, the hierarchy may be defined using the ROOT/NODE tag and one or more NODE tags. Both tags have identical syntax, but the ROOT/NODE tag is used to identify the first node in the hierarchy. 
     &lt;ROOT/NODE name=name&gt; 
     where name is the text string which will be used to identify the node programmatically. Within the scope of the ROOT/NODE tag, the TITLE, ICON, ENABLE, DISABLE, SHOW, HIDE, REFRESH, and DISPLAY tags discussed above may be specified. In addition, the NODE tag described below may also be specified. 
     NODE Tag 
     &lt;NODE&gt;&lt;/NODE&gt; 
     The NODE tag identifies a node within the tree. Any number of child nodes may be specified, and the nodes may be nested to any depth. Within the scope of the NODE tag, the ENABLE, DISABLE, SHOW, HIDE, REFRESH, and DISPLAY tags may also be specified to indicate what action(s) should be taken when the tree item represented by the NODE tag is selected. 
     Subpanels and Nesting 
     In the preferred embodiment, three types of complex subpanels may be defined within the scope of the PANEL tag: split panes, deck panes, and tabbed panes. These subpanels may also nest within one another, which means they can also be declared in document scope (the scope of the PDML tag). Unlike panels, property sheets and wizards described below, subpanels are incapable of being defined in a standalone window or dialog. 
     SPLITPANE Tag 
     The SPLITPANE tag defines a subpanel containing two windows separated by a graphical divider. Each window consists of a panel defined using the Panel Definition Markup Language. The orientation of the two windows may be controlled via the orientation attribute. 
     &lt;SPLITPANE name=name orientation=“horizontal”|“vertical”&gt; 
     where name is the text string which will be used to identify the split pane programmatically. Within the scope of the SPLITPANE tag, the TITLE and LOCATION tags discussed above may be specified. In addition, the PANE tag described below may also be specified. 
     &lt;PANE resource=resource_name name=panel_name type=“panel”|“split”|“deck”|“tab”/&gt; 
     The panel for each window is identified using the PANE tag. The resource_name argument is the resource bundle name associated with the panel, and panel_name is the name of the panel specified in the PDML document (the panel need not be defined in the same PDML document as the split pane declaration). The type argument provides the user interface framework with an indication of whether the panel is a simple panel, another split pane, a deck pane, or a tabbed pane. Note that no SIZE tag is needed. The size of the split pane is completely determined by the size of its constituent panels. When the split pane is displayed, the panels will appear in the order declared within the SPLITPANE tag. 
     DECKPANE Tag 
     The DECKPANE tag defines a subpanel containing a series of windows which are displayed one at a time. The subpanel acts as a stack or “deck” of windows. Each window consists of a panel defined using the Panel Definition Markup Language. 
     &lt;DECKPANE name=name&gt; 
     where name is the text string which will be used to identify the deck pane programmatically. Within the scope of the DECKPANE tag, the TITLE, LOCATION, and PANE tags discussed above may be specified. Note that no SIZE tag is needed. The size of the deck pane is completely determined by the size of the largest of its constituent panels. The user interface framework provides the means for the application to access and display any of the deck pane panels at runtime. 
     TABBEDPANE Tag 
     The TABBEDPANE tag defines a subpanel containing a tabbed pane with one or more tabbed windows. Each window consists of a panel defined using the Panel Definition Markup Language. The placement of the tabs may be controlled via the placement attribute. 
     &lt;TABBEDPANE name=name placement=“top”|“bottom”|“left”|“right”&gt; 
     where name is the text string which will be used to identify the tabbed pane programmatically. Within the scope of the TABBEDPANE tag, the TITLE, LOCATION, and PANE tags discussed above may be specified. Note that no SIZE tag is needed. The size of the tabbed pane is completely determined by the size of the largest of its constituent panels. When the tabbed pane is displayed, the tabbed panels will appear in the order declared within the TABBEDPANE tag. 
     Property Sheets and Wizards 
     In addition to panels defined using the PANEL tag, two additional types of standalone windows are supported within the scope of the PDML tag: property sheets and wizards, as described below. Note that the user interface framework will set the correct platform look and feel for these aggregate panels, just as it does for individual panels. 
     PROPERTYSHEET Tag 
     The PROPERTYSHEET tag defines a property sheet containing a tabbed pane with one or more tabbed windows. Each window consists of a panel defined using the Panel Definition Markup Language. The standard OK, Cancel and Help buttons are provided. 
     &lt;PROPERTYSHEET name=name&gt; 
     where name is the text string which will be used to identify the property sheet programmatically. Within the scope of the PROPERTYSHEET tag, the TITLE and ICON tags discussed above may be specified. In addition, the PAGE tag described below may also be specified. 
     PAGE Tag 
     &lt;PAGE resource=resource_name name=panel_name/&gt; 
     The panel for each property sheet page is identified using the PAGE tag. The resource_name is the resource bundle name associated with the panel, and panel_name is the name of the panel specified in the PDML document. The panel need not be defined in the same PDML document as the property sheet declaration. When the property sheet is displayed, the tabbed panels will appear in the order declared within the PROPERTYSHEET tag. 
     WIZARD Tag 
     The WIZARD tag defines a wizard panel containing a series of windows that guide the user through the performance of a particular task. Each window consists of a panel defined in PDML. Back, Next, Finish, Cancel and Help buttons are provided, as well as an optional “task list” on the left side of the wizard window, which shows the user&#39;s progress through the wizard by “checking off” each task as it is performed. 
     &lt;WIZARD name=name&gt; 
     where name is the text string which will be used to identify the wizard programmatically. Within the scope of the WIZARD tag, the PAGE tag discussed above may be specified, in addition to the STEP tag described below. 
     STEP Tag 
     &lt;STEP&gt;title&lt;/STEP&gt; 
     The left margin of the wizard may contain a list of steps required to accomplish the task which allow users to monitor their progress. The title argument is the text string which describes a step. An attempt will be made to load the string from the resource bundle associated with the wizard definition, using title as the key. If the string is not found, the title string as it appears in the PDML will be displayed. When the wizard is displayed, the steps will be shown in the order in which they are declared. 
     Referring to FIG. 11, a user interface panel  1100  provides similar components as the user interface panel  300  in FIG. 3, but instead of using a Windows resource script, the panel  1100  is defined in PDML. The PDML representation of the panel in FIG. 11 is shown in FIGS. 12A-12E. Note that a field in the panel begins with the tag name enclosed in &lt; &gt;marks, and ends with the same tag name preceded by a forward slash / to signal the end of that field, similar to the syntax used in HTML. Referring to FIG. 12A, first the PDML root is defined at line  1210 . Next, a panel named IDD_SUPPORTED_COMPONENTS is defined in the TITLE tag in line  1220 . The panel size of 400 by 300 logical units is then defined using the SIZE tag in line  1230 . This ability to specify the exact size of the panel is one of the features that distinguishes PDML from HTML, and makes it more suitable for displaying panels. Next, a button named IDOK is defined in line  1240 , with a size of 50 logical units wide by 14 logical units high, at a location of 109 logical units in the X (or horizontal) direction from the panel origin, and 279 logical units in the Y (or vertical) direction from the panel origin. The panel origin is arbitrarily defined as the upper left corner of the panel&#39;s display area. In similar fashion, each component is defined to have an origin at its upper left corner. All components are then specified in cartesian coordinates, with the first coordinate representing the distance in logical units to the right of the panel origin to the component origin, and the second coordinate representing the distance in logical units below the panel origin to the component origin. In this fashion, the size and location of the panel and components in the panel can be precisely determined by a programmer entering the appropriate size and coordinates for the panel in PDML. 
     The rest of the components in the panel of FIG. 11 are defined in the PDML code of FIGS. 12A through 12E. A correlation of the PDML code in FIGS. 12A-12E with the various components in the panel of FIG. 11 in light of the detailed tag discussion above provide a concrete example to help the reader understand the specific syntax and grammar that is used in PDML. 
     One specific embodiment of the panel conversion tool  128  of FIG. 1 is shown as item  1300  in FIG.  13 . This particular panel conversion tool  1300  includes logic to convert a Windows resource script (.rc) file  1310  to a corresponding PDML file  1320  and associated resource bundle  1330 . Note that PDML file  1320  corresponds to a suitable PDML panel  124  in FIG. 1, and resource bundle  1330  corresponds to a suitable resource bundle  125  in FIG.  1 . The components defined in Windows resource script are similar enough to the components defined in PDML that the translation between the two is primarily an exercise in mapping a resource script component to a corresponding PDML component until all of the components in the Windows resource script have been processed. Panel conversion tool  1300  allows platform-specific user interface panels to be converted to platform-independent panels in PDML format with associated resource bundles, which allows for quickly and efficiently converting panels for use in platform-independent applications or applets. 
     A major benefit of a language like PDML is that all of the information for a given user interface panel is centralized in a single XML document. The preferred embodiments take full advantage of this feature by providing a help generator tool  129  of FIG. 1 that parses the PDML for a panel and produces an online help skeleton in HTML. A suitable example for a help skeleton for the user interface panel of FIG. 11 is shown in FIG.  14 . Using the information imbedded in the PDML, the help generator tool  129  determines which user interface components require context sensitive help, and automatically assigns anchor identifiers that are derived from the names of the components. Thus, the Text Area component has a corresponding anchor identifier called Text Area. Help generator tool  129  then generates HTML skeleton  1410  which contains space for overview help for the panel, context help for each component, and task or “How do I . . . ?” help. The context help sections are presented in a logical top-to-bottom, left-to-right order according to how the user interface components are arranged on the panel. Online help text added to a previous version of a skeleton will be preserved on subsequent calls to the help generator tool  129 . 
     When a user clicks the Help button on a panel, an HTML viewer pane will be displayed showing the overview help, with links to the component help sections, as shown in the panel of FIG.  14 . If a user presses F 1  while a pointing to a particular anchor identifier (corresponding to a user interface component), or if a user clicks on a particular anchor identifier, the HTML viewer will link directly to the context help for that anchor identifier, as shown by the panel in FIG.  15 . The developer can then enter help text for each anchor identifier. This approach frees the panel developer from having to verify that links between user interface components and the corresponding context sensitive help material are functioning correctly. Support for aliasing a component to the context help for another component is also provided in the PDML tags discussed in detail above. 
     The Panel Definition Markup Language (PDML) described herein provides a platform-independent way for defining user interface panels. PDML is defined using extensible markup language (XML). A panel may be manually generated by programming directly in PDML. PDML is a markup language that uses tags in a similar fashion as HTML. PDML is thus much easier to learn and use than a complex programming language such as Java or C++. PDML provides for precise placement of components in a panel, unlike the Java layout managers. A PDML panel may also be generated graphically using a graphical editor. Using a graphical editor requires no programming skills at all to generate platform-independent user interface panels. A PDML panel may also be generated by converting a platform-specific user interface panel to a PDML panel using a conversion tool. In addition, a help generator tool facilitates the generation of context-sensitive help by providing a help skeleton with the appropriate links to panel components. The PDML and associates tools described herein provide a significant improvement over the prior art by allowing precise placement of components in a user interface panel without requiring detailed knowledge of object oriented programming, such as Java or C++. 
     One skilled in the art will appreciate that many variations are possible within the scope of the present invention. Thus, while the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that these and other changes in form and details may be made therein without departing from the spirit and scope of the invention. For example, while the best mode of the invention disclosed in the preferred embodiments herein show specific tags with specific arguments, many variations in tags and arguments are within the scope of the present invention. The present invention expressly extends to any specification language that allows generating platform-independent user interface panels in a way that gives the developer precise control over the position of components in the panel.