BACKGROUND OF THE INVENTION

&null;0001&null; 1. Field of Invention

&null;0002&null; The present invention relates generally to the field of editing and browsing XML documents. More specifically, the present invention is related to a system and a method for generating multiple customizable interfaces for XML documents.

&null;0003&null; 2. Discussion of Prior Art

&null;0004&null; The Internet and the World Wide Web (WWW) have an important and influential role in today's society. One of the most common authoring languages used to create documents on the WWW is the HyperText Markup Language or HTML. HTML is similar to the Standard Generalized Markup Language or SGML, although it is not a strict subset. HTML defines the structure and layout of a WWW document via tags and attributes.

&null;0005&null; One of the primary goals of HTML was to mark up information according to its meaning, without regard to how this information would actually be rendered in a browser. This is accomplished by using fundamental elements which hold various values. For example, the elements &null;TITLE&null;, &null;H1&null;, &null;EM&null; (or &null;STRONG&null;), and &null;ADDRESS&null; hold various values corresponding to the title, main header, emphasized text, and contact information of an author. Utilizing similar elements (other than the fundamental elements) like &null;FONT&null; to get a nice layout makes it cumbersome to present the information, and yet still maintain the best possible effect regardless of the user's environment. Added elements make the processing (at the viewer's end) of HTML documents difficult, or even impossible at times. Thus, the decision of how the viewer's browser displays titles, headers, etc., is best left to the browser, since it has access to the users' personal preferences and environment.

&null;0006&null; But, this is not the case because all the additional layout information is placed outside the HTML documents themselves. One common way to accomplish this is by placing these additional elements in a file called the CSS. CSS, or short for Cascading Style Sheets, is a feature that allows HTML authors and Web site developers to have control over how pages are displayed. With CSS, designers and users can create style sheets that define how different elements, such as headers and links, appear. These style sheets can then be applied to any Web page.

&null;0007&null; As a direct result of individualized styling of Web documents, a lot of pages now contain tagging written for a specific version of a specific browser (with default preferences) and a specific screen resolution. These pages are often more or less unreadable to those who use a different browser. Thus, HTML has turned into a language that is browser-specific.

&null;0008&null; Another pitfall associated with HTML is that it is a language that is not user-specific. Thus, it is not possible for a user to mark up information precisely based on its meaning (since a lot of the personalized elements needed are not available in HTML). For example, chemists who want special elements for chemical formulas or measurement data, are not able to do so. On the other hand, to expect a language to hold various elements involving a myriad of categories is not a feasible idea.

&null;0009&null; In addition to the above-mentioned shortcomings, HTML is not a structured language. To overcome these shortcomings, a new standard for the creation of markup language called XML was introduced.

&null;0010&null; XML or Extensible Markup Language, a specification developed by the W3C. XML is a pared-down version of SGML, designed especially for Web documents. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations. XML is becoming the universal language for data on the Web. It gives developers the power to deliver structured data from a wide variety of applications to the desktop for local computation and presentation. XML allows the creation of unique data formats for specific applications. It is also an ideal format for server-to-server transfer of structured data. XML is a subset of SGML that provides a uniform method for describing and exchanging structured data in an open, text-based format, and may deliver this data by use of the standard HTTP protocol or other similar application layer protocols. XML is poised to supplement HTML as the standard Web formatting specification. At the present time, Microsoft&null; Internet Explorer version 5 handles XML using CSS while Netscape&null; is still experimenting with XML support.

&null;0011&null; XML allows the application programmer to specify a schema that defines the structure of any XML document that uses that schema. There are two ways to specify a schema, the first is XML schema, a developing standard that allows the application programmer to describe the schema using an XML document. XML schema also provides extended functionality such as data typing and inheritance. An alternative to XML schema is the document type definition (DTD). DTDs are written using a syntax different than that of XML schema and do not provide as much functionality.

&null;0012&null; Although XML has all these advantages, there are some limitations associated with the editing and browsing of XML documents. Existing XML editing and browsing tools produce a standard view of all XML documents. Specifically, most prior art systems lack a schema specific interface utilizing components to support multiple input and output modes. FIG. 1 illustrates a prior art scenario wherein XML schema 100 is analyzed by prior art system 102 (e.g., BeanMaker or Editormaker). Next, the system generates a single component 104 that helps create schema specific interface 106. Another prior art system, Xeena, provides for schema analysis as well as front end rendering. It should however be noted that all prior art systems mentioned above create schema specific interfaces based on only one component per schema. None of these systems generate mode specific components that can interact to produce multi-modal views of data.

&null;0013&null; In addition, some prior art methods allow specification of interfaces by creating an XML document conforming to a specified schema (e.g., UIML, VoiceXML). The problem with such methods is that they require a technical person to write the XML-based specification. This scenario is illustrated in FIG. 2, wherein user 200 hard codes XML-based specification 202, which is a custom XML document conforming to a specified schema and prior art system 204 utilizes document 202 to generate schema specific interface 206. It should however be noted that these prior art methods fail to automatically generate a specification based upon the schema.

&null;0014&null; Whatever the precise merits, features and advantages of the above prior art systems, none of them achieve or fulfills the purposes of the present invention. The present invention generates mode specific components that can interact to produce a user-specific, document specific, multi-modal interface. These and other objects are achieved by the detailed description that follows.

SUMMARY OF THE INVENTION

&null;0015&null; The present invention disclosure describes a system that, based upon an XML Schema and a set of user customization rules, will produce a set of components that interact to provide a user-specific, document-specific, multi-modal interface for an XML document. Each generated component provides a specific input and output mode. A series of the components work together to produce a multi-modal view of the XML tree. One component could be HTML component, which produces a HTML rendering of the XML tree while another component may be a speech-based rendering of the tree. The present system allows these multiple component views of the XML schema to work together.

&null;0016&null; The present invention thus allows for an intuitive method of interaction with XML data and also allows for the access for all users despite input/output restrictions. Furthermore, the method also allows users to customize an interface based upon their preferences.

BRIEF DESCRIPTION OF THE DRAWINGS

&null;0017&null; FIG. 1 illustrates a prior art system that generates a single component for a schema specific interface.

&null;0018&null; FIG. 2 illustrates a prior art system that requires a user to generate custom XML documents conforming to a specified schema.

&null;0019&null; FIG. 3 illustrates a general overview of the present invention

&null;0020&null; FIG. 4 illustrates a detailed overview of the current invention.

&null;0021&null; FIG. 5 illustrates examples of components as described in FIG. 3

&null;0022&null; FIG. 6 illustrates the present invention's method for generating multiple customizable interfaces for XML documents.

&null;0023&null; FIG. 7 illustrates the present invention's system for generating multiple customizable interfaces for XML documents.

&null;0024&null; FIG. 8 illustrates the process of code-generation.

&null;0025&null; FIG. 9 illustrates the architecture of the mediator and maker interfaces.

&null;0026&null; FIG. 10 illustrates code-generation for a sample document type definition.

&null;0027&null; FIG. 11 illustrates how a schema is analyzed via steps one and two as shown in FIG. 10.

&null;0028&null; FIG. 12 illustrates the architecture of the rendering system.

&null;0029&null; FIG. 13 illustrates rendering of a sample code based on the system of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

&null;0030&null; While this invention is illustrated and described in a preferred embodiment, the invention may be produced in many different configurations, forms and materials. There is depicted in the drawings, and will herein be described in detail, a preferred embodiment of the invention, with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and the associated functional specifications for its construction and is not intended to limit the invention to the embodiment illustrated. Those skilled in the art will envision many other possible variations within the scope of the present invention.

&null;0031&null; As described above, existing XML editing and browsing tools are limited in their support. They produce a standard view of all XML documents. The present invention provides for a method to navigate and modify XML data in an intuitive way. Such a method must provide a means to allow novice users as well as users of non-traditional computing devices (e.g., cellular phones) to access XML data.

&null;0032&null; FIG. 3 illustrates a general overview of the present invention. XML schema 300 and a set of user customization rules 302 are analyzed by component generator 304, which in turn generates a series of components: &null;component 1&null; 306, &null;component 2&null; 308, . . . , &null;component n&null; 310. As a next step, a select set of the generated components interact 312 to provide a user-specific, document specific, multi-modal interface 314. This is distinctly different from the prior art system described in FIG. 1 wherein only one component is generated.

&null;0033&null; FIG. 4 illustrates a detailed overview of the current invention. Schema 402, and optionally rule specification files 400, are analyzed using code-generation algorithm 404. Code-generation algorithm 404 in turn produces a set of components (&null;component 1&null; 406 though &null;component n&null; 408) that interact to provide a user-specific, document specific, multi-modal interface for XML document 410. Each generated component provides a specific input and output mode. A series of the components then work together with rendering system 412 to produce a multi-modal view (via user interaction 414) of XML document 410. Rendering system 412 is responsible for controlled synchronized rendering (of the XML tree) and for interacting with user 414 to allow specialized input/output modes.

&null;0034&null; Hence, the present solution allows for an intuitive method of interaction with XML data and also allows access for all users despite input/output restrictions. Furthermore, the current method allows users to customize interface based upon preference.

&null;0035&null; FIG. 5 illustrates examples of the components described in FIG. 3 (&null;component 1&null; 306, &null;component 2&null; 308, . . . , &null;component n&null; 310) and FIG. 4 (&null;components 1&null; 406 though &null;component n&null; 408). In one embodiment, one component is an HTML component 502, which produces a HTML rendering of the XML tree. In another embodiment, the component is a speech component 504, which produces speech-based rendering of the XML tree. In a preferred embodiment, the present system allows multiple component views of the XML schema to work together to produce a user-specific, document specific, multi-modal interface 506.

&null;0036&null; FIG. 6 illustrates the present invention's method 600 for generating multiple customizable interfaces for XML documents. First, the present system analyzes an XML schema 602 and secondly, it optionally analyzes a set of user customization rules 604. Next, a set of components are generated via code-generation and last, a select set of components are rendered 608 via a rendering system which interacts with the user to allow specialized input/output modes.

&null;0037&null; FIG. 7 details a system 700 for generating multiple customizable interfaces for XML documents. First, XML-schema-analyzer 702 analyzes XML schema and next, user-customization-analyzer 704 optionally analyzes a set of rule specification files. As a next step, component-generator 706 generates components via code-generation. During code-generation, multiple components analyze a schema and a set of user-defined rules to produce a set of generated components that will allow a user to navigate and modify the XML data. Lastly, rendering system 708 renders a selected set of generated components wherein the generated components work together to present and modify XML data based upon user directives in the supported input modes.

&null;0038&null; The two important phases associated with the present system are: code-generation and rendering. FIG. 8 illustrates the first phase (code-generation) 800, wherein the user selects isolates a series of interface generating components from the library provided 802. To generate a customized interface, the user needs only to select those components that will be relevant to the runtime rendering scenario. Each component is responsible for making a specialized interface for an XML document and hence must implement the present invention's maker interface. In addition, the user may optionally specify a set of customization rules 804 that further define how the document will be rendered. The result of code-generation is a set of Java classes designed to mediate communication between the user and the synchronized tree manager 806. Therefore, the maker-generated classes should minimally implement our mediator interface. Since each mediator is designed to be independent of the others, the user needs only to select and invoke the mediators that are relevant to the current scenario and hence not incur the overhead of having to run all mediators simultaneously. The architecture of mediator and maker interfaces are illustrated in FIG. 9. During code-generation, each element declared in schema 900 is analyzed. For each element of schema 900, makers 908, 910, 912 are notified of the content model of the node. Based upon the content model, makers 908, 910, 912 will generate the portion of mediators 902, 904, 906 that will handle output rendering and input traversal and modification of a node with the given content model.

&null;0039&null; As an example, assume a maker were creating a Java Swing UI for an XML document of the given schema and furthermore, assume the following DTD:

&null;0040&null; <&null;ELEMENT PersonList (Name)*>

&null;0041&null; <&null;ELEMENT Name (EMPTY)>

&null;0042&null; <&null;ATTLIST Name

&null;0043&null; First CDATA &null;REQUIRED

&null;0044&null; Last CDATA &null;REQUIRED>

&null;0045&null; Code-generation for this DTD would proceed as shown in FIG. 10. In step one, schema 1000 is analyzed by schema processor 1002, which along with Swing UI maker 1004 create a sub-component Java Swing UI for the XML document. In step two, schema 1008 is analyzed and further passed through schema processor 1010 and swing UI maker 1012 to create another sub-component Java Swing UI for the XML document. Lastly, in step three 1006, the system recognizes the end of schema and wires together the sub-components and swing component 1014 is generated.

&null;0046&null; FIG. 11 illustrates in further detail how schema is analyzed via steps one and two as shown in FIG. 10. In step one, first, a label for &null;PersonList&null; is generated 1100 and next, a label for &null;Names&null; is created 1102. Finally, a list is also generated 1104. In step two, first, a panel with label &null;Name&null; is generated 1106 and next, a label for &null;First&null; is generated 1108. As a next step, a text area is created right next to the label &null;First&null; 1110 and a new label called &null;Last&null; is generated 1112. Lastly, a text area near the label &null;Last&null; is generated 1114. As described above, these sub-components, generated via these two steps, are wired together to create a swing component.

&null;0047&null; The second important phase of the present invention's system is rendering. The architecture of the rendering system is provided in FIG. 12. The system includes renderer 1200 that is responsible for controlling synchronized rendering of XML tree 1202. Each mediator 1204, 1206, 1208 acts as an intermediary between the renderer 1200 and the user allowing its own specialized input and output mode. Moreover, mediators 1204, 1206, 1208 provides the capability to follow links between XML documents.

&null;0048&null; The Renderer defines the concept of a cursor. At any given point, all of the registered mediators should be rendering the portion of the tree pointed to by the cursor. When the cursor is moved, the new view of the tree should be rendered. However, it is possible that a mediator will have to move the cursor more than one time to achieve the desired view. This is because the methods to move the cursor are generally incremental and somewhat limited. To accommodate this situation, the renderer implements a locking mechanism. Before calling a method that will move the cursor, the given mediator must acquire the lock. After all movement is complete, the lock should be released. When the lock is released, all of the mediators are notified that the cursor has changed. If a mediator directs that a link be followed, the renderer will follow the link and possibly instantiate new mediators if necessary.

&null;0049&null; To illustrate rendering using an example, the following document is used:

&null;0050&null; <PersonList >

&null;0051&null; <Name First&null;&null;Mickey&null; Last&null;&null;Mouse&null;/>

&null;0052&null; <Name First&null;&null;Donald&null; Last&null;&null;Duck&null;/>

&null;0053&null; <Name First&null;&null;Minnie&null; Last&null;&null;Mouse&null;/>

&null;0054&null; </PersonList >

&null;0055&null; In this example, the mediators includes a Swing UI (discussed in the schema analysis example) and an aural mediator that provides speech-based input and output for the user. FIG. 13 illustrates, in one embodiment, how this scenario might proceed. First, the user opens document using renderer 1302 and two mediators 1304. Second, the user sees a frame with the label &null;PersonList&null; 1306 and under this is label &null;Names&null; 1308 and a list containing the text, &null;Mickey Mouse, Donald Duck, Minnie Mouse&null;. In addition, the user hears, &null;Person list document. Please select name one, two, or three.&null; Then, the user double clicks on &null;Donald Duck&null; 1310 and a frame appears containing label &null;Name&null; 1312 under which are two more labels, &null;First&null; 1314 and &null;Last&null; 1316. Next to &null;First&null; is the name &null;Donald&null; 1318 and next to last is the name &null;Duck&null; 1320. The user then hears, &null;You selected Donald Duck&null; 1322. Furthermore, the user says &null;Change Donald to Daisy&null; 1324 and the text area previously containing &null;Donald&null; now changes to &null;Daisy&null; 1326. In addition, the user hears, &null;The current name is Daisy Duck&null; 1328 and the user says &null;Exit&null; and the program exits.

&null;0056&null; The above system and its described functional elements are implemented in various computing environments. For example, the present invention may be implemented on a conventional IBM PC or equivalent, multi-nodal system (e.g., LAN) or networking system (e.g., Internet, WWW, Wireless Web). All programming and data related thereto are stored in computer memory, static or dynamic, and may be retrieved by the user in any of. conventional computer storage, display (i.e., CRT) and/or hardcopy (i.e., printed) formats. The programming of the present invention may be implemented by one of skill in the art of XML programming.

CONCLUSION

&null;0057&null; A system and method has been shown in the above embodiments for the effective implementation of a system and method for generating multiple customizable interfaces for XML documents. While various preferred embodiments have been shown and described, it will be understood that there is no intent to limit the invention by such disclosure, but rather, it is intended to cover all modifications and alternate constructions falling within the spirit and scope of the invention, as defined in the appended claims. For example, the present invention should not be limited by software/program, computing environment, specific computing hardware. In addition, the specific chosen components are representative of the preferred embodiment and should not limit the scope of the invention. The invention could be practiced locally or across networks, including, but not limited to, LANs, WANs, WWW, Internet, cellular, satellite, virtual, etc.