Method and apparatus for representing host datastream screen image information using markup languages

[0002] 1. Technical Field

[0003] The present invention relates generally to an improved data processing system and, in particular, to a method and apparatus for representing screen data from a host computer using a markup language.

[0004] 2. Description of Related Art

[0005] Some display devices that are used to present information from mainframe-type host computers have limited capabilities for displaying a user-friendly graphical user interface (GUI). These devices may have a graphic mode, but much of the information is text-only. A host datastream directed to a terminal connected to the host computer, e.g., IBM 3270 and 5250 terminals, typically describes a rectangular host screen image that can be viewed as a character-based structure of fields. The datastream is a shorthand representation for the screen containing both content and formatting attributes. For example, a sequence of 10 blank characters starting from position 100 is described by a repeat command followed by a starting position of 100, an ending position of 109, and a single blank character.

[0006] Other platforms that provide user-friendly graphical user interfaces may use host emulation software. However, the information that is received and sent must still conform to the format expected by the host computer. Parsing the host datastream is a major task of a typical host datastream emulation application.

[0007] Most emulators avoid redundant parsing by storing the resulting parsed information for later reference. The host screen image information and associated information is stored in an internal data structure or presentation space to support the rendering of the host screen image and the interactions between the two applications at the ends of the datastream.

[0008] Some previous solutions to the problems of creating a presentation space have used proprietary programming language structures. For example, Java-based emulation software may represent a presentation space using a Java object while a C-based emulation application represents the presentation space using C structures. Representing a presentation space in a proprietary programming language structure prevents the presentation information from being interchangeable in a multi-product, multi-language, or multi-tier environment.

[0009] Proprietary presentation spaces create difficulties in adopting different presentation styles. For example, in a server-based environment, the server can not share a presentation space with its clients. A client needs to establish a special purpose, proprietary communications protocol with the server. The client then requests that the server run a service written to the proprietary presentation space application programming interface (API) in order for the server to retrieve requested information that the client requires to continue its processing. These iterations add significant communications overhead.

[0010] Some previous solutions to the problems of creating a presentation space have chosen to duplicate a partial presentation space at the client. This may reduce the communications overhead but locks the application into a specific proprietary protocol and introduces other overhead for maintaining states for two presentation spaces.

[0011] In the case of GUI customization for host screens, some previous solutions have typically reconstructed the presentation space information in a proprietary database with additional customizing information for each host screen. The GUI software checks every host screen for matching customizing information in the database to convert it to a different presentation style and maps back user inputs and interactions to keystrokes in the original presentation space. This process incurs the overhead of reconstruction, definition, mapping, and remapping of the same host data in several data structures. Furthermore, the resulting presentation style is locked into a specific customized database that is difficult to migrate to different presentation styles.

[0012] In other solutions, an application typically needs to employ the legacy presentation space interfaces and formats. As has become apparent over the past few years, legacy systems may be costly, skill-dependent, and error-prone.

[0013] The previous solutions do not present host screen data in a commonly interchangeable format that is easily integrated with other applications and independent of presentation styles. Therefore, it would be advantageous to represent host screen image information in a manner, which is flexible, pervasive, and requires less programming effort. It would be further advantageous for the solution to adhere to open programming and open data standards.

[0014] The present invention provides a method and apparatus for representing host datastream screen image information using markup languages. A distributed data processing system contains a network, at least one host computer, at least one client computer, and optionally at least one server. The host computer generates a host datastream containing host screen image information and forwards the host datastream to a client. If the client is not directly connected to the host, then the host datastream may be routed to the client. The host datastream is converted to a markup language tagged datastream at some point within the network according to a Document Type Definition (DTD) authored for the purpose of representing information in host datastreams. The client receives the markup language tagged datastream containing the host screen image information derived from the host datastream and parses the markup language tagged datastream to identify the host screen image information. The host screen image information is displayed on a display device connected to the client, enabling the client to act as an emulator for the host.

[0015] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[0016] FIG. 1 depicts a pictorial representation of a distributed data processing system in which the present invention may be implemented;

[0017] FIG. 2 depicts a data processing system that may be implemented as a server;

[0018] FIG. 3 depicts a data processing system that may be implemented as a client;

[0019] FIG. 4 is a block diagram depicting a distributed data processing system comprising a server that contains a mid-tier converter for converting a host datastream to an XML datastream;

[0020] FIG. 5 is a block diagram depicting a distributed data processing system containing a client and mainframe whose applications communicate by means of XML datastreams without modifying the applications to understand XML datastreams;

[0021] FIG. 6 is a block diagram depicting a distributed data processing system that has a client computer that accepts XML datastreams from a mainframe application executing on a mainframe host computer in which the mainframe application generates an XML datastream;

[0022] FIG. 7 is a block diagram depicting a distributed data processing system with a network of servers that may employ the representation of screen images using the datastream to XML conversion;

[0023] FIG. 8 is a flowchart depicting a process within an XML server for receiving and forwarding host datastreams and XML datastreams;

[0024] FIG. 9 is a flowchart depicting the processing used by a client to receive an XML datastream and respond with a newly generated XML datastream to the server;

[0025] FIGS. 10A-10E are sections of a DTD (Data Type Definition) file that provides an example of a set of tags that allows the representation of a host screen image in XML;

[0026] FIG. 11 is a graphical representation of a screen snapshot that show a window presented to a user of a client computer that is running an emulator application connected to a host computer;

[0027] FIG. 12 is an example of a raw host datastream; and

[0028] FIGS. 13A-13C are examples of an XML datastream

[0029] With reference now to the figures, FIG. 1 depicts a pictorial representation of a distributed data processing system in which the present invention may be implemented. Distributed data processing system 100 is a network of computers in which the present invention may be implemented. Distributed data processing system 100 contains a network 102, which is the medium used to provide communications links between various devices and computers connected together within distributed data processing system 100. Network 102 may include permanent connections, such as wireless systems and wire or fiber optic cables, or temporary connections made through telephone connections.

[0030] In the depicted example, a server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 also are connected to a network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. For purposes of this application, a network computer is any computer, coupled to a network, which receives a program or other application from another computer coupled to the network. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Distributed data processing system 100 may include additional servers, clients, host computers, and other devices not shown. In the depicted example, distributed data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the TCP/IP suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, distributed data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended as an example, and not as an architectural limitation for the present invention.

[0031] With reference now to FIG. 2, a block diagram depicts a data processing system that may be implemented as a server, such as server 104 in FIG. 1, in accordance with a preferred embodiment of the present invention. Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors 202 and 204 connected to system bus 206. Alternatively, a single processor system may be employed. Also connected to system bus 206 is memory controller/cache 208, which provides an interface to local memory 209. I/O bus bridge 210 is connected to system bus 206 and provides an interface to I/O bus 212. Memory controller/cache 208 and I/O bus bridge 210 may be integrated as depicted.

[0032] Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to network computers 108-112 in FIG. 1 may be provided through modem 218 and network adapter 220 connected to PCI local bus 216 through add-in boards.

[0033] Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, server 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.

[0034] Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 2 may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.

[0035] The data processing system depicted in FIG. 2 may be, for example, an IBM RISC/System 6000 system, a product of International Business Machines Corporation in Armonk, N.Y., running the Advanced Interactive Executive (AIX) operating system.

[0036] With reference now to FIG. 3, a block diagram illustrates a data processing system in which the present invention may be implemented. Data processing system 300 is an example of a client computer, such as client 108 in FIG. 1. Data processing system 300 employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Micro Channel and ISA may be used. Processor 302 and main memory 304 are connected to PCI local bus 306 through PCI bridge 308. PCI bridge 308 also may include an integrated memory controller and cache memory for processor 302. Additional connections to PCI local bus 306 may be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter 310, SCSI host bus adapter 312, and expansion bus interface 314 are connected to PCI local bus 306 by direct component connection. In contrast, audio adapter 316, graphics adapter 318, and audio/video adapter 319 are connected to PCI local bus 306 by add-in boards inserted into expansion slots. Expansion bus interface 314 provides a connection for a keyboard and mouse adapter 320, modem 322, and additional memory 324. SCSI host bus adapter 312 provides a connection for hard disk drive 326, tape drive 328, and CD-ROM drive 330. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.

[0037] An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in FIG. 3. The operating system may be a commercially available operating system such as OS/2, which is available from International Business Machines Corporation. “OS/2” is a trademark of International Business Machines Corporation. An object oriented programming system such as Java may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system 300. “Java” is a trademark of Sun Microsystems, Inc. Instructions for the operating system, the object-oriented operating system, and applications or programs are located on storage devices, such as hard disk drive 326, and may be loaded into main memory 304 for execution by processor 302.

[0038] Those of ordinary skill in the art will appreciate that the hardware in FIG. 3 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash ROM (or equivalent nonvolatile memory) or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIG. 3. Also, the processes of the present invention may be applied to a multiprocessor data processing system.

[0039] For example, data processing system 300, if optionally configured as a network computer, may not include SCSI host bus adapter 312, hard disk drive 326, tape drive 328, and CD-ROM 330, as noted by dotted line 332 in FIG. 3 denoting optional inclusion. In that case, the computer, to be properly called a client computer, must include some type of network communication interface, such as LAN adapter 310, modem 322, or the like. As another example, data processing system 300 may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system 300 comprises some type of network communication interface. As a further example, data processing system 300 may be a Personal Digital Assistant (PDA) device which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.

[0040] The present invention provides a method for transferring datastreams in particular formats across a distributed data processing system. The depicted example in FIG. 3 and above-described examples are not meant to imply architectural limitations. The present invention may be implemented on a variety of servers, clients, and host computers as described with FIG. 1.

[0041] The present invention provides a method of representing host screen images using a markup language to markup screen data by contents, attributes, and interactions. Although the examples are provided using XML (eXtensible Markup Language), it is contemplated that some other markup languages that are compatible with the Standard Generalized Markup Language (SGML) family of languages may be used to implement the present invention. However, the SGML-compatible language must offer tag definitions through Data Type Definition (DTDs) support so that the syntax and meaning of the tags within the system may be flexible changed. For example, although Hypertext Markup Language (HTML) is within the SGML family of languages, it does not offer the flexibility required by the present invention.

[0042] More information about XML may be found in DuCharme, XML: The Annotated Specification, January 1999, herein incorporated by reference.

[0043] A host datastream is parsed once into an XML format that is interchangeable with any application. A set of tags are defined to store the field structure and character attributes of the host screen image with its data content in single data unit.

[0044] Host emulation software implementing the method of the present invention may optionally generate an XML format after it has processed an outbound host datastream, i.e. a host datastream directed from a host to a client. Host emulation software implementing the method of the present invention may also accept XML-formatted input to generate an inbound host datastream, i.e. a host datastream directed from a client to a host.

[0045] Host emulation software implementing the method of the present invention may also receive XML datastreams directly from host applications. The XML datastreams are received either via a conversion program that converts host datastreams to XML datastreams for legacy applications or from newly written host applications that are able to generate XML datastreams directly.

[0046] Examples of these different embodiments of the present invention using different configurations of distributed data processing systems are described below with respect to FIGS. 4-7.

[0047] With reference now to FIG. 4, a block diagram depicts a distributed data processing system comprising a server that contains a mid-tier converter for converting a host datastream to an XML datastream and from an XML datastream to a host datastream. Distributed data processing system 400 contains client computer 402, mainframe host computer 404, and mid-tier server computer 406. Mainframe host computer 404 executes mainframe application 408 that generates host datastream 410 addressed to client 402. XML client 412 executing on client 402 has plug-in 414 that accepts XML datastream 416 and generates XML datastreams to be returned to mainframe host computer 404. Client 402 accepts XML datastream 416, processes the XML datastream using XML client 412 and plug-in 414, and generates a display to be shown on display device 418. Client 402 can accept inputs from a user such that client 402 emulates an interface to mainframe host computer 404.

[0048] Host datastream 410 is routed through mid-tier server 406 before being routed to client 402 as XML datastream 416. Mid-tier server 406 may support an optional Web server 420 that provides access to Web pages, etc. Host server 422 executing on mid-tier server 406 accepts host datastream 410. Host server 422 may provide input/output support and appropriate application programming interfaces (APIs) that are used by other software components on mid-tier server 406. Plug-in 424 executing within XML server 426 accesses or retrieves data comprising the content of host datastream 410 and converts the content into an appropriately tagged XML datastream that is forwarded to client 402. In this example, mid-tier server 406 provides a communication path between mainframe application 408, which is only able to generate and understand host-formatted datastreams, and XML client 412, which is only able to generate and understand XML-formatted datastreams.

[0049] With reference now to FIG. 5, a block diagram depicts a distributed data processing system containing a client and mainframe hose applications communicate by means of XML datastreams without modifying the applications themselves to understand XML datastreams. Data processing system 500 contains client 502 and mainframe host 510. Client 502 has plug-in 504 that executes within XML client 506 to generate displays to a user on display device 508.

[0050] Mainframe host computer 510 has mainframe application 512 that generates data to be used by the user of client 502. Mainframe application 512 provides data through mainframe application programming interface 514 that contains functions and methods used by plug-in 516 executing within XML server 518. XML server 518 accepts datastreams from mainframe applications and converts those datastreams to XML datastreams 520 that are forwarded to XML client 506 on client 502. In this example, existing host or mainframe applications may produce datastreams on the mainframe without regard to the destination client's ability to translate a host datastream. An XML server may be created to execute on the mainframe host in order to intercept and convert datastreams from the mainframe applications to newly deployed XML clients within the distributed data processing system.

[0051] With reference now to FIG. 6, a block diagram depicts a distributed data processing system that has a client computer that accepts XML datastreams from a mainframe application executing on a mainframe host computer in which the mainframe application generates an XML datastream Distributed data processing system 600 has client computer 602 executing plug-in 604 within XML client 606 to generate presentation data for a user on display device 608. Mainframe host 608 supports mainframe XML application 610 that generates a datastream addressed to client 602. In this example, mainframe XML application 610 generates an XML datastream that is accepted by plug-in 614 within XML server 612 and forwarded to XML client 606 as XML datastream 616. In this example, new mainframe host applications may be deployed that are XML-savvy, and these applications may use an XML host data parser and generator in accordance with a preferred embodiment of the present invention.

[0052] With reference now to FIG. 7, a block diagram depicts a distributed data processing system that has a network of servers that may employ the representation of screen images using the datastream to XML conversion. Server 702 executes backend user application 704 that may provide a variety of transaction services or other enterprise applications. Server 702 may communicate with other servers 706 within distributed data processing system 700. Backend user code 704 generates a datastream that is accepted by plug-in 708 executing within XML server 710 that forwards XML datastream 726 to XML client 712 executing within server 714. Plug-in 716 executing within XML client 712 may interface with intermediate application code 718. Intermediate application code 718 may act as a server to front-end application code 720 executing within client 722. Front-end application code 720 may be similar to intermediate application code 718 such that the origin or destination of a transaction between the two applications determines which application has a clients-side perspective and which application has a server-side perspective. Client 722 then provides support for front-end application code 720 to display application presentation data on display device 724.

[0053] With reference now to FIG. 8, a flowchart depicts a process within an XML server for receiving and forwarding host datastreams and XML datastreams. The process begins when the XML server receives a host datastream (step 802). The XML server parses the host datastream (step 804) and generates an XML datastream that is properly tagged with the content from the host datastream (step 806). The XML server forwards the XML datastream to the appropriate client (step 808) and waits for the client to respond (step 810). A determination is then made as to whether a response has been received from a client (step 812). If not, then the process returns to step 810 to continue waiting for a client response. The XML server then receives the XML datastream from the client (step 814). The XML server then generates a host datastream that contains the content from the XML datastream received from the client (step 816). The XML server then forwards the newly generated XML datastream to the host (step 818). Steps 802-818 constitute an essentially non-terminating loop in which the XML server processes datastream traffic between the host and the client. In an alternative process, the XML server may continue processing other datastreams rather than waiting for a particular response from a particular client. In other words, the XML server may process multiple datastreams in parallel and asynchronously.

[0054] With reference now to FIG. 9, a flowchart depicts the processing used by a client to receive an XML datastream and respond with a newly generated XML datastream to the server. The process begins when the client receives an XML datastream from the server (step 902). The client parses and processes the XML datastream (step 904) and presents the host-generated presentation data to the user of the client (step 906). The client then accepts any inputs from the user concerning the host data (step 908) and generates an XML datastream containing the content of the user input (step 910). The client then sends the XML datastream to the server so that the server may forward the XML datastream to the host computer (step 912).

[0055] There are many advantages to using the methods of the present invention.

[0056] Host screen images stored in the XML format can be accessed directly by different software components implemented in different languages without regard to language compatibility issues, which facilitates integration of XML-based host data sources with other data sources.

[0057] XML-based host screen images can be easily customized to different display formats by applying different display stylesheets or rendering engines. For example, with a browser supporting XML and eXtensible Stylesheet Language (XSL), the host screen image can be displayed directly inside the browser without any programming effort. Different style sheets may be adopted by particular users as a preference option. XML is also an ideal format for storing the host image as an intermediate format for future processing or as a format for servers to exchange data.

[0058] An important point is host datastreams need only be processed once on a given system The commonly understood XML format may be forwarded around the network for use by other applications, which may include but are not limited to: data source integration, presentation customization, distributed processing, and/or conventional host data entry processing. A distinct advantage of using XML is that little semantic meaning is lost in the conversion from a host datastream to an XML datastream.

[0059] Although portions of a distributed data processing system may implement the above described methods as stand-alone applications or software components, in order to deploy a complete, distributed, data processing system that implements various aspects of the present invention, the following components are desirable: a set of tags for assignment to a representation of host screen images; software components for parsing or generating XML-based host screen image datastreams; common transport across a network; and host to XML datastream conversion.

[0060] With reference now to FIGS. 10A-10E, a DTD (Data Type Definition) file provides an example of a set of tags that allows the representation of a host screen image in XML. A DTD is a grammar that describes what tags and attributes are valid in an XML document or datastream that refers to the DTD and in what context the tags and attributes are valid. An attribute is a name=“value” pair that can be placed in the start tag of an element. In the present invention, the set of tags in the DTD provides meaning to the data, which represents the field structure of the host screen.

[0061] The DTD shown in FIG. 10A-10E separates the information representing a host screen image into two parts: session information and screen information. The “Session” element delimited by the tag-pair “<session> </session>” contains information about the host session, such as host session ID, host type, host name, host port number, and host session screen size. The session information is originated from initiation parameters sent to the converter or from a client connecting to an XML application directly. The “Screen” element delimited by the tag-pair “<screen> </screen>” is the main element describing both the contents and attributes for a host screen image and contains three sub-elements: content, interaction, and display.

[0062] The “content” element describes the detailed information about the host screen fields including both text content and text attributes (for example, field start position, length, protected or unprotected, field text, etc.).

[0063] The “interaction” element specifies an inbound function key (i.e., a function key that may request some type of processing from the host within the emulator environment) or hints from outbound for expected inbound responses (i.e., a small amount of information from the host on expected input from a user within the emulator environment).

[0064] The “display” element stores the host-application-generated screen-display-related information, such as background and foreground color. The advantage of separating out the display information is that it facilitates filtering the display information when only the host screen content is requested, which saves potential processing and transmission overhead. With this set of tags, content and formatting attributes of host screen images are preserved in a common format that is available to any application for further processing without dependence on special purpose programming interfaces, such as EHLLAPI (Emulator High-Level Language API, which is a C-based API for writing emulator applications) and HACL (Host Access Class Library, which is an API to create Host Access Java Beans running on top of HACL provided within the Host On-Demand or HOD software platform environment). A client-side application interacts with host applications directly via the interaction tags. Screens can be bookmarked easily for further processing, such as off-line transactions. The presentation style is totally independent of the original host application designated attributes.

[0065] With reference now to FIG. 11, a graphical representation of a screen snapshot shows a window presented to a user of a client computer that is running an emulator application connected to a host computer. In this example, the client computer is an IBM PC-compatible personal computer running an application under Microsoft Windows™. The client has formatted the host datastream into an XML datastream before presenting the host screen image, which in this example is a login screen.

[0066] With reference now to FIG. 12, an example of a raw host datastream is shown. Host datastream 1200 is the raw unprocessed, unparsed data that would be received by an XML client from a host-based application. In this example, the content of host datastream 1200 is a portion of the login screen content shown in the emulator window in FIG. 11. Host datastream 1200 has command 1202 that informs an application to write the datastream to the display device. Order 1204 sets the display buffer address to coordinate “C1D1”. Order 1206 starts a field at the given point with a field attribute value equal to “F8”. Content portion 1208 specifies the content of a field with its character values in brackets immediately beneath.

[0067] With reference now to FIGS. 13A-13C, an example of an XML datastream is shown. The content of the XML datastream is the login screen content shown in the emulator window in FIG. 11 after parsing and tagging the raw host datastream shown in FIG. 12.

[0068] In addition to the set of tags, two software components provide facilities for the conversion of the XML-based representation into a programming language's data structure for application development. The two additional elements are an XML-based host screen image parser and generator. The parser parses the XML representation and transforms it into an object tree that holds its information. The generator performs the reverse function by generating the XML-form of the host screen image from the object tree. These provide a different programming interface than special purpose programming interfaces such as EHLLAPI and HACL, which are usually employed in prior art systems to obtain the presentation space information containing host screen images.

[0069] The XML datastreams are directly accessible to applications that incorporate the parser and the generator as convenience tools to simplify the programming effort. Parsers and generators are generally well known in the art for parsing and generating markup languages. The parser provides one with the ability to extract the host screen image from the XML data and perform some type of processing. The generator gives one the ability to generate the XML-based form and forward it to another software component for further processing.

[0070] The XML datastreams can be forwarded across the network of a distributed data processing system through a common transport mechanism over sockets. The transport is generally used symmetrically at both ends of the application stream. The mechanism automatically wraps XML datastreams into socket stream objects and optionally applies an XML host data parser and generator to transmit an object tree from end-to-end in the application stream.

[0071] The XML datastreams can be generated directly by an application or converted to or from a host datastream by an existing host application. A host-XML datastream converter establishes a session with the host application and converts one type of datastream to the other bi-directionally. The converter can be an integral part of the emulation software to enhance its capability. The converter may appear in various forms, as shown with respect to FIGS. 4-7: it may be wrapped as a JavaBean to interact with an HOD session bean or may take the form of a plug-in to a client server, host server (e.g., tn3270/5250 server), or host application to enhance their communications capabilities.

[0072] The advantages of the present invention should be apparent in light of the detailed description. Previous solutions have used a language specific data structure to represent the host screen image. Sharing, formatting, and integration of the presentation space information have been done through specific software written to a specific interface. This approach has the disadvantages of requiring extra programming redundancies and efforts and of being non-pervasive and inflexible. This present invention uses a common XML format to represent the host screen image, which makes the host screen image information interchangeable and easy to share. Reduced programming effort is required as knowledge of markup languages becomes more available. Customizing the display of the host screen image is flexible. Application designers merely supply different display style sheets to show different looks for the host screen image. Integration with other data sources is pervasive and follows a common XML standard. Host-based data processing is much easier with more direct availability of to the host-generated data.

[0073] It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links.

[0074] The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.