United States Patent Application20030225829
Kind CodeA1
Pena, Armando ; et al.December 4, 2003

System and method for platform and language-independent development and delivery of page-based content
Abstract
A system and method for platform and language-independent delivery of page-based content. Content defined in a relatively abstract format is rendered into multiple platform formats in client-side applications' user interfaces in multiple human languages. The relatively abstract format is a subset of XML and is used to define user interface elements to be displayed on a page. A Model-View-Controller architecture is implemented comprising a plurality of servlet filters, a servlet pipeline and a plurality of rendering processors for client detection, client tracking, relatively abstract format preprocessing, relatively abstract format processing and validating, and transforming and rendering of the relatively abstract format into multiple platform formats in client-side applications' user interfaces in multiple human languages. A creation, modification and management tool is also disclosed for creating, modifying and managing platform and language-independent page-based content.

Inventors:Pena; Armando (Duarte, CA), Spring; Leslie  (Granada Hills, CA), Hjelming; Andreas  (Marina Del Rey, CA), Hsui; Galvin  (Los Angeles, CA), Hollenbeck; Todd  (Hermosa Beach, CA), Hamoui; Omar  (Los Angeles, CA)
Correspondence Name and Address:2029 CENTURY PARK EAST SUITE 3500
FOLEY & LARDNER
LOS ANGELES
CA
90067

Series Code:262600
Filed:September 30, 2002
U.S. Current Class:709/203; 709/205
U.S. Class at Publication:709/203; 709/205
Intern'l Class:G06F 015/16

Claims


What is claimed is:
1. A system with at least one server and a plurality of client network enabled devices communicating content to and from the at least one server via a network such that the content is displayed in a user interface of each of the plurality of client network enabled devices, at least one of the plurality of client network enabled devices displaying the content in one of multiple platform formats or in one of multiple human languages that is different from that of at least one other of the plurality of client network enabled devices, the system comprising: a plurality of renderers; and a processor programmed for: parameterizing user interface (UI) elements of a user interface in a relatively abstract format; accepting requests for content from the network enabled devices; determining platform formats and human languages used by the network enabled devices to display the content on the user interface; delegating the requests to the plurality of renderers for rendering the determined platform formats and human languages; and outputting rendered content to the network enabled devices for display on the user interface based on the determined platform formats and human languages.

2. The system recited in claim 1, wherein the user interface (UI) elements include at least one of user interface (UI) components, actions, copy, and rendering elements.

3. The system recited in claim 1, further comprising at least one data source for providing the content.

4. The system recited in claim 3, wherein the at least one data source is a database.

5. A system with at least one server and a plurality of client network enabled devices communicating content to and from the at least one server via a network, the system comprising: at least one data source for providing content in a relatively abstract format; and a rendering layer comprising a plurality of rendering processors for accepting the content in the relatively abstract format from the at least one data source and transforming the content in the relatively abstract format into content in multiple platform formats in multiple human languages and for outputting the content in the multiple platform formats for display on the network enabled devices.

6. The system recited in claim 5, further comprising: a plurality of object filters for detecting a request from the network enabled devices and for determining platform formats of the network enabled devices; and a plurality of objects for delegating the request to appropriate rendering objects based on the platform formats of the network enabled devices determined by the plurality of object filters.

7. The system recited in claim 5, wherein the plurality of rendering processors comprise a user interface (UI) preprocessor for recursively resolving external references in the content in the relatively abstract format in a source document and dynamically inserting the resolved references into an output document.

8. The system recited in claim 7, wherein the user interface (UI) preprocessor resolves primitive paths, resource paths and copy element texts in the content and dynamically inserts the resolved primitive paths, resource paths and copy element texts into the output document.

9. The system recited in claim 5, wherein the plurality of rendering processors comprise a user interface (UI) processor for accepting content in a relatively abstract format and resolving scriptlet elements and handling taglibs.

10. The system recited in claim 5, wherein the plurality of rendering processors comprise an Extensible Style Sheet Transformations (XSLT) processor for dynamically building a list of Extensible Style Sheet Transformations (XSLT) references for a generalized mark-up language stylesheet given an input of content in the relatively abstract format, and for performing a transformation of the content in the relatively abstract format into content in multiple platform formats.

11. The system recited in claim 10, wherein the generalized mark-up language is at least one of eXtensible Markup Language (XML) and Standard Generalized Markup Language (SGML).

12. The system recited in claim 10, wherein the Extensible Style Sheet Transformations (XSLT) processor finds primitives paths, builds Extensible Style Sheet Transformations (XSLT) references using primitive paths, and runs the relatively abstract format with the Extensible Style Sheet Transformations (XSLT) references through an Extensible Style Sheet Transformations (XSLT) transformer.

13. The system recited in claim 5, wherein the multiple platform formats comprise at least one of HyperText Markup Language ("HTML"), Wireless Markup Language ("WML"), compact HTML ("cHTML"), Flash, Clie', Playstation 2 (PS2), and Wireless Application Protocol ("WAP").

14. The system recited in claim 5, wherein the content in multiple platform formats is displayed on the network enabled devices as user interfaces.

15. The system recited in claim 5, wherein the content comprises rendering elements for defining user interfaces on the network enabled devices.

16. The system recited in claim 15, wherein the rendering elements comprise rendering primitives that act as functional elements of the user interfaces.

17. The system recited in claim 15, wherein the rendering primitives include render locations that define locations of the of at least one of the rendering elements.

18. The system recited in claim 15, wherein the rendering primitives include rendering resources that act as graphical elements of the user interfaces.

19. The system recited in claim 15, wherein the rendering elements comprise action elements for parameterizing actions performed by a user on the user interfaces.

20. The system recited in claim 15, wherein the rendering elements comprise user interface (UI) elements for parameterizing the user interfaces.

21. The system recited in claim 5, wherein the at least one data source is a database.

22. The system recited in claim 5, wherein the at least one data source is an external application.

23. The system recited in claim 5, further comprising a gateway object for delegating object requests to particular ones of the plurality of rendering processors.

24. The system recited in claim 5, further comprising a user interface (UI) preprocessor object for invoking the user interface (UI) preprocessor when an input document having content in the relatively abstract format is received.

25. The system recited in claim 6, wherein the objects are Java objects.

26. The system recited in claim 25, wherein the Java objects are Java servlets.

27. The system recited in claim 6, wherein the plurality of object filters comprises at least one object filter for determining whether or not the network enabled devices are known and can be tracked.

28. The system recited in claim 27, wherein when the network enabled devices are known and can be tracked, the at least one object filter logs this information.

29. The system recited in claim 6, wherein the plurality of object filters and the plurality of objects are Java objects.

30. The system recited in claim 29, wherein the Java objects are Java servlets.

31. The system recited in claim 5, wherein the request is an HTTP request.

32. The system recited in claim 5, further comprising an object bridge layer for relating data tables to objects and automatically implementing object persistence to the data source.

33. The system recited in claim 5, further comprising a Simple Object Access Protocol (SOAP) interface for allowing exchanges of information over the network.

34. The system recited in claim 33, wherein the information is exchanged based on the eXtensible Markup Language (XML) standard.

35. The system recited in claim 5, further comprising schema domain managers for providing standardized logic to different application servers.

36. The system recited in claim 35, wherein the standardized logic is based on an Enterprise Java Beans ("EJB") specification.

37. The system recited in claim 35, wherein the standardized logic includes an asset manager EJB for creating, removing and updating content.

38. The system recited in claim 35, wherein the standardized logic includes a content manager EJB for creating, removing and updating content and for retrieving associated metadata.

39. The system recited in claim 35, wherein the standardized logic includes a metadata manager EJB for creating, removing and updating a Metadata item.

40. The system recited in claim 35, wherein the standardized logic includes a metadata type manager EJB for creating, removing and updating metadata types.

41. The system recited in claim 35, wherein the standardized logic includes a country manager EJB for creating, removing and updating a country record.

42. The system recited in claim 35, wherein the standardized logic includes a file manager EJB for creating, removing and updating a file item.

43. The system recited in claim 35, wherein the standardized logic includes a file extension manager EJB for creating, removing and updating a file type and an associated extension.

44. The system recited in claim 35, wherein the standardized logic includes a user manager EJB for creating, removing and updating a user record.

45. The system recited in claim 35, wherein the standardized logic includes a user interface (UI) copy manager EJB for creating, removing and updating a user interface (UI) copy record.

46. The system recited in claim 35, wherein the standardized logic includes a renderer resource manager EJB for creating, removing and updating a RendererResource record.

47. The system recited in claim 35, wherein the standardized logic includes a renderer primitive manager EJB for creating, removing and updating a RendererPrimitive item.

48. The system recited in claim 35, wherein the standardized logic includes a renderer type manager EJB for creating, removing and updating a RendererType item.

49. The system recited in claim 35, wherein the standardized logic includes a language manager EJB for creating, removing and updating a Language item.

50. The system recited in claim 35, wherein the standardized logic includes a relatively abstract format user interface (UI) manager EJB for creating, removing and updating a RelativelyAbstractFormat user interface (UI) item.

51. The system recited in claim 35, wherein the standardized logic includes a relatively abstract format scriptlet manager EJB for creating, removing and updating relatively abstract format Scriptlet item.

52. The system recited in claim 35, wherein the standardized logic includes a relatively abstract format action manager EJB for creating, removing and updating a relatively abstract format Action item.

53. A system with at least one server and a plurality of client network enabled devices communicating content to and from the at least one server via a network such that the content is displayed in a user interface of each of the plurality of client network enabled devices, at least one of the plurality of client network enabled devices displaying the content in one of multiple platform formats or in one of multiple human languages that is different from that of at least one other of the plurality of client network enabled devices, the system comprising: means for parameterizing user interface (UI) elements of the user interface in a relatively abstract format; means for accepting requests for content from the network enabled devices; means for determining platform formats and human languages of the network enabled devices; means for delegating the requests to renderers for rendering the determined platform formats and human languages; and means for outputting rendered content to the network enabled devices based on the determined platform formats and human languages.

54. A computer program product, comprising: a storage medium; and program instructions stored on the storage medium for: parameterizing user interface (UI) elements of a user interface in a relatively abstract format; accepting requests for content from network enabled devices for display on associated user interfaces; determining platform formats and human languages for displaying the content on the associated user interfaces; delegating the requests to renderers for rendering the determined platform formats and human languages; and outputting rendered content to the network enabled devices for display on the associated user interfaces based on the determined platform formats and human languages.

55. In a system with at least one server and a plurality of client network enabled devices communicating content to and from the at least one server via a network, a method for platform and language-independent delivery of page-based content, the method comprising: accepting content in a relatively abstract format from at least one data source; and transforming the content in the relatively abstract format into content in multiple platform formats in multiple human languages and outputting the content in the multiple platform formats and multiple human languages for display on the network enabled devices.

56. The method recited in claim 55, wherein the content is output to the network enabled devices in response to a request.

57. The method recited in claim 56, wherein the request is an HTTP request.

58. The method recited in claim 56, further comprising: detecting the request from the network enabled devices; determining platform formats of the network enabled devices; and delegating the request to appropriate renderers based on the determined platform formats of the network enabled devices.

59. In a system with at least one server and a plurality of client network enabled devices communicating content to and from the at least one server via a network such that the content is displayed in a user interface of each of the plurality of client network enabled devices, at least one of the plurality of client network enabled devices displaying the content in one of multiple platform formats or in one of multiple human languages that is different from that of at least one other of the plurality of client network enabled devices, the method comprising: parameterizing user interface (UI) elements of the user interface in a relatively abstract format; accepting requests for content from the network enabled devices; determining platform formats and human languages for displaying the content on the user interface; delegating the requests to renderers for rendering the determined platform formats and human languages; and outputting rendered content to the network enabled devices for display on the user interface based on the determined platform formats and human languages.

60. The method recited in claim 59, further comprising storing the parameterized user interface (UI) elements in at least one data source.

61. The method recited in claim 59, wherein the user interface (UI) elements include at least one of user interface (UI) components, actions, copy, and rendering elements.

62. The method recited in claim 59, wherein the relatively abstract format is an interface definition mark-up language (IDML) which is based on a generalized markup language.

63. The method recited in claim 62, wherein the generalized markup language is at least one of eXstensible Mark-up Language (XML) and Standard Generalized Markup Language (SGML).

64. The method recited in claim 62, wherein the interface definition mark-up language (IDML) comprises a primitive tag for parameterizing primitives to be displayed in the user interface.

65. The method recited in claim 64, wherein the primitive tag contains at least one of rendering resources and text.

66. The method recited in claim 64, wherein the primitive tag comprises attributes including at least one of a business name, a render location, and an IDML element identification (ID).

67. The method recited in claim 64, wherein the primitive tag comprises nested tags including at least one of a copy text tag and a resource tag.

68. The method recited in claim 62, wherein the interface definition mark-up language (IDML) comprises a resource tag for specifying rendering resources to be displayed in the user interface.

69. The method recited in claim 62, wherein the resource tag comprises attributes including at least one of a business name and a render location.

70. The method recited in claim 62, wherein the interface definition mark-up language (IDML) comprises a text tag for specifying copy text to be displayed in the user interface.

71. The method recited in claim 70, wherein the text tag comprises attributes including at least one of a business name and a render location.

72. The method recited in claim 62, wherein the interface definition mark-up language (IDML) comprises a collection tag for parameterizing collections to be displayed in the user interface.

73. The method recited in claim 72, wherein the collection tag contains at least one of primitives, other collections, rendering resources and text.

74. The method recited in claim 72, wherein the collection tag comprises attributes including at least one of a business name, a render location, an IDML element identification (ID) and a action identification (ID).

75. The method recited in claim 72, wherein the collection tag comprises nested tags including a copy text tag, a resource tag, another collection tag, and a primitive tag.

76. The method recited in claim 62, wherein the interface definition mark-up language (IDML) comprises a primitive list tag for parameterizing iterative collections.

77. The method recited in claim 76, wherein the primitive list tag comprises a nested item tag.

78. The method recited in claim 76, wherein the interface definition mark-up language (IDML) further comprises a list wrapper tag for wrapping the primitive list tag.

79. The method recited in claim 76, wherein the primitive list tag comprises a type="array" attribute for Flash compatibility.

80. The method recited in claim 62, wherein the interface definition mark-up language (IDML) comprises an item tag for wrapping individual items in a primitive list.

81. The method recited in claim 80, wherein the item tag comprises nested tags including at least one of a primitive tag, a collection tag, a list wrapper tag, and a primitive list tag.

82. A user interface for use with a content creation, modification and management system, comprising a user interface (UI) elements list interface including means for displaying user interface (UI) elements representing content stored in at least one data source in a relatively abstract format.

83. The user interface recited in claim 82, further comprising: means for searching the user interface (UI) elements according to designated search criteria; means for sorting the user interface (UI) elements by categories; means for linking the user interface (UI) elements to editing interfaces; and means for adding selected user interface (UI) elements to a publishing list.

84. The user interface recited in claim 82, further comprising: means for creating new user interface (UI) elements; and means for deleting selected user interface (UI) elements.

85. The user interface recited in claim 82, further comprising: a "View/Edit" user interface (UI) elements interface comprising: means for viewing and editing user interface (UI) elements; and means for saving new and edited user interface (UI) elements to the at least one data source as content in a relatively abstract format.

86. The user interface recited in claim 85, further comprising means for entering metadata to be associated with selected user interface (UI) elements including at least one of a name, a description, content, filepath, filename and text, wherein the user interface (UI) elements are saved along with the associated metadata.

87. The user interface recited in claim 82, wherein the user interface (UI) elements include at least one of user interface (UI) components, actions, copy, and rendering elements.

88. The user interface recited in claim 82, wherein the user interface (UI) elements are user interface (UI) components and further comprising means for determining whether the user interface (UI) components are referenced by other user interface (UI) components.

89. The user interface recited in claim 88, further comprising a "Verify" user-selectable operator selectable for updating the status field.

90. The user interface recited in claim 85, wherein the user interface (UI) elements include at least one of user interface (UI) components and actions and further comprising a relatively abstract format editing window for editing relatively abstract format code.

91. The user interface recited in claim 82, wherein the categories include at least one of name, description, status, text, identification (ID), language, renderer, file type, size, item ID, and UI element type.

92. The user interface recited in claim 87, wherein the actions include embedded data for defining links to user interface (UI) elements including at least one of sub-actions, copy, assets, and rendering elements.

93. The user interface recited in claim 85, wherein the user interface (UI) elements include copy elements and further comprising a copy text editing window for editing copy text.

94. The user interface recited in claim 93, wherein at least two items of copy text are associated with a named copy element.

95. The user interface recited in claim 93, further comprising means for selecting one or more languages for which the copy text will be used during rendering.

96. The user interface recited in claim 93, further comprising means for selecting one or more renderers for rendering the copy text.

97. The user interface recited in claim 94, wherein the rendering elements contain contextual information for displaying content within a page defined in the relatively abstract format.

98. The user interface recited in claim 92, wherein the rendering elements include subsets of rendering elements including at least one of rendering resources and rendering primitives.

99. The user interface recited in claim 92, wherein the rendering elements include at least one sub-item grouped by at least one of file, language and renderer.
100. The user interface recited in claim 85, wherein the user interface (UI) elements include rendering elements and further comprising means for selecting one or more languages for which the rendering element will be used during rendering.
101. The user interface recited in claim 85, wherein the user interface (UI) elements include rendering elements and further comprising means for selecting one or more renderers for rendering the renderiing element.
102. The user interface recited in claim 82, further comprising a files list interface including means for displaying files list in the at least one data source.
103. The user interface recited in claim 102, further comprising: means for searching the files according to designated search criteria; means for sorting the files by categories; means for linking the files to editing interfaces; and means for adding selected files to a publishing list.
104. The user interface recited in claim 102, further comprising: means for creating new files; and means for deleting selected files.
105. The user interface recited in claim 102, further comprising: a "View/Edit" files interface comprising: means for viewing and editing files; and means for saving new and edited files to the at least one data source.
106. The user interface recited in claim 105, further comprising means for entering metadata to be associated with selected files including at least one of a name, a description, content, filepath, and a filename, wherein the files are saved along with the associated metadata.
107. The user interface recited in claim 82, further comprising a publishing list interface including means for displaying publishing list items.
108. The user interface recited in claim 107, further comprising means for moving publishing list items from the at least one data source to at least one other data source.
109. The user interface recited in claim 108, further comprising means for selecting the at least one other data source.
110. The user interface recited in claim 107, further comprising: means for sorting the publishing list items by categories; and means for linking the publishing list items to editing interfaces.
111. The user interface recited in claim 107, further comprising means for determining a publication status of the publishing list items.
112. The user interface recited in claim 107, further comprising means for removing selected publishing list items from the publishing list interface.
113. The user interface recited in claim 107, further comprising means for removing all publishing list items from the publishing list interface.
114. The user interface recited in claim 82, further comprising a "View/Edit" configuration interface for setting global configuration data for the content creation, modification and management system.
115. The user interface recited in claim 114, wherein the global configuration data includes at least one of IP addresses for various environments in a publishing pipeline and root file system paths used to create and manage relative file path data for file objects within the at least one data source.
116. The user interface recited in claim 114, further comprising means for setting an error checking level that is applied whenever at least one of a user interface (UI) component and action is saved to the at least one data source.
117. The user interface recited in claim 116, wherein the error checking level includes at least one of ignoring errors, warning about errors and trapping errors.
118. The user interface recited in claim 114, further comprising means for selecting for direct editing at least one of an active environment and a data source environment.
119. The user interface recited in claim 115, further comprising means for entering an IP address, wherein the IP address defined a location of instances of services of the content creation, modification and management system for each stage in the publishing pipeline.
120. The user interface recited in claim 119, wherein the system services are a set of Simple Object Access Protocol (SOAP)-based APIs enabling at least one of the content creation, modification and management system and network enabled devices to communicate with the at least one data source in a controlled and well defined manner.
121. The user interface recited in claim 115, wherein the publishing pipeline includes multiple stages and wherein for each stage in the publishing pipeline, a disk-based file system is used to store physical files that are used by the content creation, modification and management system.
122. The user interface recited in claim 121, wherein relative file paths are stored in file objects in the at least one data source and wherein the user interface further comprises means for entering root file paths of at least one of an active environment and a source environment for searching and selecting files in the at least one of an active environment and a source environment.
123. The user interface recited in claim 122, wherein when files are selected, the root file paths are stripped from full file paths of the file to provide the relative file paths, the relative file paths being saved to the at least one data source.
124. The user interface recited in claim 82, further comprising means for applying changes made in the user interface.

Description



BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates generally to transfer of content between a server and multiple network enabled client devices operating on different platforms over a network such as the Internet, and more particularly to rendering content in a relatively abstract format into multiple platform formats in client-side applications' user interfaces in multiple human languages.

[0003] 2. Description of Related Art

[0004] The popularity of the Internet has engendered a number of devices having a capability for providing access to the Internet. As illustrated in FIG. 1, such devices include desktop and laptop computers, cellular phones and personal digital assistants ("PDAs"). The various different types of network enabled devices ("NEDs") may each operate with a different platform format ("platform"), for example by operating with different web-based or non-web-based browser types.

[0005] The term "content" is used herein to refer to all forms of electronic content (i.e., content that may be read or processed in an electronic form), including, but not limited to, digital video, audio, photos, graphics, text and animation. When a provider of content desires to provide to different platforms access to the content, the provider may be required to build, for example, custom web pages or other content containing pages for each specific platform format. That is, the provider would need to provide pages or other content resources formatted in HyperText Markup Language ("HTML"), Wireless Markup Language ("WML"), compact HTML ("cHTML"), and so on, to conform to the device/browser display capabilities. This is both labor intensive to initially setup and difficult to maintain as changes are made to the site's data and services.

[0006] Therefore, it can be seen that there is a need for a system and method for accepting content defined in a relatively abstract format and transforming the relatively abstract format input into a specific recognized platform format for a particular device.

SUMMARY OF THE DISCLOSURE

[0007] Therefore, embodiments of the present invention provide a system and method for platform and language-independent delivery of page-based content.

[0008] Embodiments of the present invention provide a system and method for accepting content defined in a relatively abstract format and transforming the relatively abstract format input into a specific recognized platform format for a particular device.

[0009] Embodiments of the present invention further provide a system and process for creating, modifying and managing platform and language-independent page-based content.

[0010] Embodiments of the present invention further provide a relatively abstract format for defining content in a data source. The relatively abstract format may be transformed into multiple platform formats in client-side applications' user interfaces in multiple human languages.

[0011] In one embodiment, a system and method for platform and language-independent delivery of page-based content implements a Model-View-Controller architecture comprising a plurality of servlet filters, a servlet pipeline and a plurality of rendering processors for client detection, client tracking, relatively abstract format preprocessing, relatively abstract format processing and validating, and transforming and rendering of the relatively abstract format into multiple platform formats in client-side applications' user interfaces in multiple human languages.

[0012] In another embodiment, a system and method for platform and language-independent delivery of page-based content implements creation, modification and management tool that allows a creator or publishing team to create, modify, and manage platform and language-independent page-based content. The page-based content can then be viewed and interacted with by end-users, with embodiments of the system and method for platform and language-independent delivery of page-based content being used to display the same content on multiple platforms, and in multiple languages.

[0013] In yet another embodiment, a format in the form of an interface definition mark-up language ("IDML") is provided for defining a relatively abstract format to be transformed into multiple platform formats in client-side applications' user interfaces in multiple human languages. In one embodiment, IDML is a subset of eXstensible Mark-up Language ("XML") and may be fully compliant with all XML standards. IDML is used to define user interface elements within embodiments of the system and method for platform and language-independent delivery of page-based content. Keywords and rules are defined for IDML which allow a user to accurately specify a user interface to be rendered by a rendering group within the system for platform and language-independent delivery of page-based content.

[0014] These and other features, and advantages of embodiments of the invention will be apparent to those skilled in the art from the following detailed description of embodiments of the invention, when read with the drawings and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Referring now to the drawings in which like reference numbers represent corresponding parts throughout:

[0016] FIG. 1 illustrates a number of devices having a browser or user agent capability communicating with a server over the Internet;

[0017] FIG. 2 illustrates an exemplary hardware/software environment wherein, embodiments of the system and process of the present invention may be employed;

[0018] FIG. 3 illustrates a network environment where a server communicates with various network enabled devices, each having a platform-specific language for displaying content within a browser/user agent, according to embodiments of the present invention;

[0019] FIG. 4 illustrates an exemplary web page for display on a client network enabled device, according to embodiments of the present invention;

[0020] FIG. 5 shows a simplified block diagram illustrating an exemplary pipeline for platform and language-independent delivery of page-based content, according to embodiments of the present invention;

[0021] FIGS. 6A through 6D show exemplary rendering elements that may be used to populate pages, according to embodiments of the present invention;

[0022] FIG. 7 shows a high level block diagram illustrating a server-side backend system for platform and language-independent delivery of page-based content, according to embodiments of the present invention;

[0023] FIG. 8 shows a diagram illustrating the functions of an MVC architecture, according to embodiments of the present invention;

[0024] FIG. 9 shows a simplified block diagram of a system including web tier, according to embodiments of the present invention;

[0025] FIG. 10 shows a flowchart illustrating an HTTP request flow, according to embodiments of the present invention;

[0026] FIG. 11 shows a simplified block diagram of a system, showing a relation of a data service layer to a web tier and database on a server side, and client network-enabled devices and a .Net client tool on the client side, according to embodiments of the present invention;

[0027] FIG. 12 shows an exemplary schema of a database for storing rendering elements, action elements, UI elements and copy, according to embodiments of the present invention;

[0028] FIG. 13 shows a simplified block diagram of a mark-up language rendering group within web tier, along with a database and a data service layer, according to embodiments of the present invention;

[0029] FIG. 14 shows a simplified block diagram of a Flash rendering group, along with a database, a data service layer and a web tier, according to embodiments of the present invention;

[0030] FIG. 15 shows an example IDML document structure, according to embodiments of the present invention;

[0031] FIG. 16 shows an exemplary UI components list interface, according to embodiments of the present invention;

[0032] FIG. 17 shows an exemplary "View/Edit" UI component interface, according to embodiments of the present invention;

[0033] FIG. 18 shows an exemplary actions list interface, according to embodiments of the present invention;

[0034] FIG. 19 shows an exemplary "View/Edit" action interface, according to embodiments of the present invention;

[0035] FIG. 20 shows an exemplary copy list interface, according to embodiments of the present invention;

[0036] FIG. 21 shows an exemplary "View/Edit" copy interface, according to embodiments of the present invention;

[0037] FIG. 22 shows an exemplary rendering elements list interface, according to embodiments of the present invention;

[0038] FIG. 23 shows an exemplary "View/Edit" rendering elements interface, according to embodiments of the present invention;

[0039] FIG. 24 shows an exemplary files list interface, according to embodiments of the present invention;

[0040] FIG. 25 shows an exemplary "View/Edit" files interface, according to embodiments of the present invention;

[0041] FIG. 26 shows an exemplary publishing list interface, according to embodiments of the present invention;

[0042] FIG. 27 shows an exemplary "View/Edit" file configuration interface, according to embodiments of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0043] In the following description of embodiments of the invention, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of embodiments of the present invention.

[0044] As discussed above, the present invention relates generally to a system and process for transferring content between a server and multiple network enabled client devices operating on different platforms over a network such as the Internet. Embodiments of the present invention address the need for a system and method for accepting content defined in a relatively abstract format and transforming the relatively abstract format input into a recognized platform format specific for a particular device.

[0045] A system and process for platform and language-independent delivery of page-based content, according to embodiments of the present invention, may be used with various types of hardware/software combinations. FIG. 2
illustrates an exemplary hardware/software environment 200 wherein embodiments of the system and process of the present invention may be employed.

[0046] The system 200 may include a computer workstation 202, a computer monitor 204, and input devices such as a keyboard 206, and mouse 208. The workstation 102 may also include input/output interfaces 212, storage 214, such as a disk 216 and random access memory (RAM) 218, as well as one or more processors 220. The workstation 102 may be a computer workstation such as a Windows NT-type workstation or other suitable computer or computers. The computer monitor 204, keyboard 206, and mouse 208, as well as other input devices such as, but not limited to, video tape recorders, cameras, and hardware accelerators (not shown) may be used to interact with various software elements of the system residing in the memory of the workstation 202 to cause processes to be performed on data. The system 200 in FIG. 2 is shown by way of illustration and not limitation. Other systems may be used to implement embodiments of the invention.

[0047] System and device functions and processes described herein may be implemented with machine-executable instructions. Software comprising these instructions may be used to program and cause general-purpose or special-purpose processors to perform the functions and processes described herein. Alternatively, such functions and processes may be implemented by firmware, hardware comprising hardwired logic, or by any combination thereof.

[0048] Embodiments of the invention may be employed in a network environment where a server communicates with various network enabled devices (NEDs), each having a platform-specific language for displaying content within a browser or user agent. Such a network environment 300 is shown in FIG. 3. Content 302 is provided via web server 304 and the Internet 306 to NEDs 308, 310 and 312, each of which may operate with different platforms, for example HTML, cHTML, WML and so on.

[0049] Embodiments of the invention may be employed with systems and methods described in co-pending U.S. utility patent applications entitled "Media Content Creating and Publishing System and Process," Ser. No. 09/906,024, filed Jul. 13, 2001, "Content Management System and Process," Ser. No. 09/906,023, filed Jul. 13, 2001, and "Dynamic Graphical Index Of Website Content," Ser. No. 09/915,608, filed Jul. 26, 2001, the content of all of which is incorporated by reference herein.

[0050] FIG. 4 shows an exemplary web page for display on a client NED. The exemplary tool application page 400 shown in FIG. 4 provides media creation and editing tools and digital assets that may be used to create and edit various media. Tool application page 400 comprises tool application area 402, "experience" channel area 404, (comprising user-selectable operators 410 (action), 412 (comedy), 414 (drama), 416
(music), and 418 (science fiction) for selecting a genre of media content), a "create" user-selectable operator 406, a "connect" user-selectable operator 408, interactive advertising space 420, and menu area 422.

[0051] Tool application page 400 may further comprise promotes for additional tools, such as tool promotes 424, 426, and 428. Tool application page 400 may also further comprise promotes for additional asset packs, such as asset pack promotes 430 and 432. Tool application page 400 may further comprise user-selectable operators that activate ("launch") tool poppers containing additional media content creating and editing functionality.

[0052] According to embodiments of the present invention, tool application page 400 is created with a creation tool that allows a creator or publishing team to create, modify, and manage platform and language-independent page-based, graphic, or other content. The page-based content can then be viewed and interacted with by end-users on multiple platforms (such as, but not limited to, HTML, cHTML, WML and Flash), and in multiple human languages (such as, but not limited to, English, Spanish and Japanese) by rendering content in a relatively abstract format into multiple platforms and multiple human languages in user interfaces of client-side applications.

[0053] In one embodiment, a system and method for platform and language-independent delivery of page-based content uses a separate "thin" rendering group for each supported platform, allowing common user interface ("UI") elements to be shared by multiple platforms and hardware devices. In other embodiments, a system and method for platform and language-independent delivery of page-based content alternatively, or in addition, operates in cooperation with one or more client-side platform renderers such as, but not limited to, a Windows application renderer, a Flash renderer and a Playstation 2 ("PS2") renderer.

[0054] In one embodiment, the common UI elements may comprise rendering elements, action elements and UI elements, and copy elements (titles, paragraphs, etc.) that are used to populate pages such as tool application page 400 shown in FIG. 4. The common UI elements may be defined in a relatively abstract format and stored in a system database. The common UI elements defined in the relatively abstract format may be accessed by client-side devices via a system server. The common UI elements in the relatively abstract format are then transformed by embodiments of the invention's system and method into multiple platform formats in client-side applications' user interfaces in multiple human languages.

[0055] Alternatively, or in addition, the common UI elements or other data in a relatively abstract format may be obtained from other data sources besides a system database, including, but not limited to, another application external to the system itself. As an example, a shopping cart application could write data in a relatively abstract format back to the system and the system could then render it and return it to the shopping cart application in a particular platform format. As another example, a NED such as a Bluetooth-enabled digital camera may receive a user interface from an application on a host computer, enabling the camera to upload pictures to an external storage device. Furthermore, content may be provided from multiple data sources using, for example, rendering dynamic XSLT. The multiple data sources may include, but are not limited to, databases, 3rd party applications, or any other source that generates data in a relatively abstract format.

[0056] In one embodiment, the relatively abstract format may be a proprietary interface definition mark-up language ("IDML"). IDML may be a subset of XML and may be fully compliant with all XML standards. However, in other embodiments, the system and method for platform and language-independent delivery of page-based content may be modified such that IDML may be defined by other generalized mark-up languages such as, but not limited to, Standard Generalized Markup Language ("SGML").

[0057] FIG. 5 shows a simplified block diagram illustrating an exemplary pipeline for platform and language-independent delivery of page-based content, according to embodiments of the present invention. As illustrated by the block diagram shown in FIG. 5, in one embodiment the UI elements 506, 508 and 510 stored in a database are specified in the relatively abstract format during preprocessing and recursion 512. UI elements 506, 508 and 510 are then rendered into various desired client platforms, for example Flash client 520, HTML client 522 and any other supported platform ("Any Platform") client 524. In the case of thin clients such as HTML client 522, the UI elements 506, 508 and 510 defined in the relatively abstract format may be received by HTML rendering group 516, which renders the UI elements 506, 508 and 510 into the HTML client platform. Thick clients such as Flash client 520 may comprise a Flash rendering group 514 that may receive the UI elements 506, 508 and 510 in the relatively abstract format and render them into SWF files. In the case of Any Platform client 524 (representing additional supported client platforms such as, but not limited to, Clie', PS2, and Wireless Application Protocol ("WAP") enabled devices), "Any Platform" rendering group 518 may receive the UI elements 506, 508 and 510 defined in the relatively abstract format and render them into the desired "Any Platform" client platform.

[0058] During preprocessing and recursion 512, a complete page or other content resource in the relatively abstract format is assembled from the individual UI elements 506, 508 and 510. In addition, names of the rendering elements and copy, for example business names, are resolved based on the client platform and language. Rendering groups are responsible for translating the relatively abstract format into the target platform. According to embodiments of the present invention, one rendering group may be required for each target platform.

[0059] In one embodiment, rendering elements are the set of rendering primitives/collections and rendering resources which make up the pages. Rendering primitives/collections may be platform specific while rendering resources may be both platform and human language specific. Rendering elements may be associated with a name and rendering platform. Rendering resources will additionally be associated with a human language.

[0060] The rendering primitives may be the actual functional elements of the pages. "Rendering primitives" may actually include both primitives and collections. The distinction is that a collection can contain one or more primitives/collections along with resources and copy, while a primitive can only contain rendering resources and copy, but not other primitives. Collections contain areas called render locations which are the actual areas that other copy, resources, primitives and collections can recursively be placed. Primitives also have render locations, but only copy or resources can be placed in those render locations. A page or other content resource is considered complete when all render locations have been filled. An example of a rendering primitive/collection 434 is shown on tool application page 400 shown in FIG. 4.

[0061] The rendering resources may be the graphical elements that are used in the pages. Typically this would consist of backgrounds, button skins, images, animations, and any other graphical elements in the pages. Rendering resources are defined by a name and they are language and platform specific.

[0062] Action elements and UI elements may be the set of generalized mark-up language code, for example XML code, that defines and parameterizes the pages. According to one embodiment, UI IDML is used to parameterize the actual UI. Action IDML is used to parameterize any actions that are taken on the pages. IDML actions allow a user to, for example, navigate and view web-based content, including, but not limited to, UI "pages/content resources" and various media. Actions may also allow users to submit data for processing to a receiving device. Thus, according to embodiments of the present invention, actions on a page may be abstracted as well as the rendered UI of the page.

[0063] Copy is the set of localized text (titles, paragraphs, etc.) that will be displayed in the pages. Copy will be associated with a name and rendering platform as well as a human language.

[0064] FIGS. 6A, 6B, 6C and 6D show exemplary rendering elements that may be used to populate, for example, tool promotes 424, 426, and 428 or asset pack promotes 430 and 432 of the tool application page 400 shown in FIG. 4. As shown in FIGS. 6A through 6D, the rendering elements may be displayed in various platform formats (Flash, HTML, cHTML, WML, etc.) and in various human languages (English, Spanish, Japanese, etc.).

[0065] FIG. 7 shows a high level block diagram illustrating a server-side backend system 700 for platform and language-independent delivery of page-based content, according to an embodiment of the present invention. According to embodiments of the present invention, the server-side backend system 700 may be implemented in Java.TM. Enterprise Edition ("J2EE.TM."). According to other embodiments, the server-side backend system 700 may be implemented in any other suitable server-side programming language, including, but not limited to, Microsoft.TM. .NET, Visual Basic, C, C++, Perl, Python, ADA, C#, Common Lisp, Dylan, Eiffel, Elastic C, Modula 3, SMALLTALK, Mesa, and Tcl/TK.

[0066] The system essentially comprises three levels: a first level is a database 702 which may store content "logical assets" and associated metadata defining logical asset attributes. In one embodiment, the logical assets are defined in IDML. The logical assets may include, but are not limited to, rendering elements, action elements and user interface ("UI") elements and copy.

[0067] The second level of the high level block diagram is a data service layer 704 which may comprise an object bridge layer that relates data tables to objects, enterprise Java bean ("EJB") schema domain managers that provide standardized logic to different application servers and a Simple Object Access Protocol ("SOAP") interface that allows HTTP commands to be invoked.

[0068] The third level of the high level block diagram is a web tier 706
which supports multiple client platforms. Types of platforms supported by the web tier 706 include thin client platforms such as, but not limited to, HTML, cHTML and WAP. Web tier 706 further supports thick client platforms such as, but not limited to, Windows applications, Flash and Playstation 2 ("PS2"). Due to this multiple client platform support capability, changes to the page flow and presentation requires low maintenance for software development. In addition, web tier 706 is extensible, scalable and fault tolerant with regards to state.

[0069] First, web tier 706 will be described in more detail. Web tier 706, according to one embodiment, uses a known Model-View-Controller ("MVC") architecture which divides applications into three layers--model, view, and controller--and de-couples their respective responsibilities. A diagram illustrating the functions of an MVC architecture 800 is shown in FIG. 8.

[0070] Each of the three layers handle specific tasks and has specific responsibilities relative to the other layers. As shown in the diagram of FIG. 8, a model 802 may represent business data and business logic or operations that govern access and modification of this business data. Often the model 802 serves as a software approximation to real-world functionality. The model 802 notifies views when it changes and provides the ability for the view to query the model 802 about its state. It also provides the ability for the controller 806 to access application functionality encapsulated by the model 802.

[0071] A view 804 renders the contents of a model. It accesses data from the model 802 and specifies how that data should be presented. It updates data presentation when the model 802 changes. A view 804 also forwards user input to the controller 806.

[0072] The controller 806 defines application behavior. It dispatches user requests and selects views for presentation. It interprets user inputs and maps them into actions to be performed by the model 802. In a stand-alone GUI client, user inputs may include, for example, button clicks and menu selections. In a Web application, user inputs may include, for example, HTTP GET and POST requests to the Web tier. The controller 806 selects the next view to display based on the user interactions and the outcome of the model operations. An application typically has one controller for each set of related functionality. Some applications use a separate controller for each client type, because view interaction and selection often vary between client types.

[0073] In software development, most of the high costs of ownership are not associated with construction (i.e. coding an application), but maintenance. As business requirements change over time, any changes to an existing software system will introduce some level of risk. The adoption of an MVC architecture for the web tier 706 separates responsibilities among model, view, and controller objects, reduces code duplication and makes applications easier to maintain. It also makes handling data easier, whether adding new data sources or changing data presentation, because business logic is kept separate from data. It is easier to support new client types, because it is not necessary to change the business logic with the addition of each new type of client.

[0074] FIG. 9 shows a simplified block diagram of a system 900 including web tier 706, according to embodiments of the present invention. Web tier 706 is shown as a part of a server side application in communication with a client network-enabled device ("NED") 902.

[0075] According to embodiments of the present invention, web tier 706 may comprise three parts: servlet filters 904, servlet pipeline 906 and rendering processors 908. These software components work together to determine the type of client and its specification (for example, HTML or WAP), store client side information per user and transform a single input in a relatively abstract format such as, but not limited to, an IDML format, for platform-specific display.

[0076] An HTTP request flow 1000, according to embodiments of the present invention, will now be described in a general manner with reference to the simplified block diagram of FIG. 9 and the flowchart shown in FIG. 10. An HTTP request is issued from the user via NED 902 at S1002. The client-side application may have a "user agent" or header that is passed to the server which maps to the right language and platform. Or a user may manually enter the language and platform information themselves or a client-side or server-side application may be provided to do this. The HTTP request is detected by the servlet filters 904 at S1004, and a determination of a client platform is made and user tracking is performed. At S1006, the HTTP request is processed in the servlet pipeline 906 for delegation and rendering. At S1008, the HTTP request is processed individually by the rendering processor components. At S1010, the HTTP request is rendered back to the user's NED 902 according to the user's client platform and human language.

[0077] The operation and inter-operation of the servlet filters 904, servlet pipeline 906 and rendering processors 908, according to embodiments of the present invention, will now be described in more detail. A servlet filter is an object that can transform a request or modify a response. A servlet filter is not a servlet, i.e., a servlet filter doesn't actually create a response. Instead, they are preprocessors of the request before it reaches a servlet, and/or postprocessors of the response leaving a servlet. A servlet filter can intercept a servlet's invocation before the servlet is called. In addition, a servlet filter can examine a request before a servlet is called and modify the request headers and request data by providing a customized version of the request object that wraps the real request. Furthermore, a servlet filter can modify the response headers and response data by providing a customized version of the response object that wraps the real response. Also, a servlet filter can intercept a servlet's invocation after the servlet is called.

[0078] In the system and method for platform and language-independent delivery of page-based content according to embodiments of the present invention, a series of servlet filters 904 acts on the struts controller gateway servlet 920 in the servlet pipeline 906. In one embodiment, servlet filters 904 comprise basic client detection servlet filter 914, advanced client detection servlet filter 916 and tracking servlet filter 918.

[0079] Basic client detection servlet filter 914 uses a browser/user agent compatibility management tool such as, but not limited to, BrowserHawk.TM., to detect the basic specifics/details of the client NED 902 such as language supported, plugins supported and basic HTML properties of the request. Basic client detection servlet filter 914 may then set client NED 902 information as a session variable.

[0080] Advanced client detection servlet filter 916 uses advanced device detection such as, but not limited to, Morphis device detection, to find the advanced details of the client, namely WAP device information such as, for example, the WAP phone make and colors supported. Advanced client detection servlet filter 916 may then set client NED 902 information as a session variable.

[0081] Tracking servlet filter 918 determines whether or not the user's NED 902 is known and can be tracked. If so, tracking servlet filter 918
may log this information to the database 702 (See FIG. 7) and/or run pattern recognition software to determine the user preferences at a later time.

[0082] Generally, a servlet pipeline may be an extensible architecture used to perform a series of operations on each incoming request. In any browser/user agent-server conversation, the browser/user agent operating on the client's NED will send the server a request. Usually the server will either find an HTML page or other content resource and send it back to the browser or user agent, or call a servlet and send the servlet's output to the browser. With a servlet pipeline, however, one servlet's output may be input to a second servlet. The Web server may send the second servlet's output to the browser, or may input it to a third servlet, and so on. The output from the last servlet in the chain may then be sent to the browser.

[0083] The servlet pipeline is a suitable point of integration when an HTTP or other non-HTTP request is being used as the method of communication between platforms, or when session-scoped data must be accessed. However the servlet pipeline should not be made excessively complex since every request must pass through it; an inefficient pipeline can compromise an application's performance.

[0084] According to embodiments of the present invention, servlet pipeline 906 may comprise a struts controller gateway servlet 920, a UI preprocessor servlet 922, a UI processor servlet 924, a Extensible Style Sheet Transformations ("XSLT") processor servlet 926 and a page/content resource compilation processor servlet 928.

[0085] The struts controller gateway servlet 920 communicates with struts controller 910. Struts controller 910 is the controller 806 in the MVC architecture described above and illustrated in FIG. 8. The struts controller gateway servlet 920 delegates the servlet requests to the appropriate action processors and determines the request servlet flow of an application.

[0086] The UI preprocessor servlet 922 invokes the rendering preprocessor component given an input IDML document. The preprocessing step involves resolving external IDML references and determining primitive and resource paths. The UI processor servlet 924 processes the refined IDML document by, for example, resolving scriptlet tags and dynamic pieces of IDML via the rendering processors 908. The UI processor servlet 924 also resolves, for example, Java Server Page ("JSP") tags and references. JSPs are text-based documents that execute as servlets.

[0087] The XSLT processor servlet 926 uses the rendering XSLT transformation component to dynamically change the relatively abstract format to a platform specific language such as, but not limited to, HTML, WAP or cHTML. The page/content resource compilation processor servlet 928
takes the transformed XSLT input and serializes the output into the output platform/language specific to the requesting device.

[0088] In the servlet pipeline 906 according to embodiments of the present invention, the struts controller gateway servlet 920 delegates the flow of the HTTP request. For example, if the struts controller 910 determines that the request is an "action" type of request, the struts framework may possibly forward the request through a completely different pipeline than for a different type of request. The power and flexibility of struts gives the servlet pipeline dynamic and stackable capabilities which allow customization options for multiple scenarios and use cases.

[0089] Rendering processors 908 will now be discussed. As discussed above, the system and method for platform and language-independent delivery of page-based content according to embodiments of the present invention, accepts a common input in a relatively abstract format and transforms the relatively abstract format input into a specific recognized platform format for a particular device. For example, a relatively abstract IDML input can be transformed for display in various platforms such as, but not limited to, a web-based or non-web-based browser, a WAP enabled cell phone or a PDA.

[0090] In one embodiment, rendering processors 908 are pluggable software components that are bound to an immutable interface. These processors may be chained together sequentially and may eventually be exposed as web services. The availability of the rendering processors 908 as web services gives access to external clients, such as NED 902, in order to process the relatively abstract format accordingly. The servlet pipeline 906 employs rendering processors 908 for displaying the client specific output to the user's NED. Rendering processors 908 communicate with servlets at each stage of the servlet pipeline 906. In one embodiment, rendering processors 908 comprise a UI preprocessor 930, a UI processor 932 and an XSLT processor 934.

[0091] UI preprocessor 930 functions to recursively resolve external relatively abstract format references in the source relatively abstract format document. These references are then dynamically inserted into the output relatively abstract format document. UI preprocessor 930 also resolves the primitive paths, the resource paths and the copy element texts. All of this information is dynamically inserted into the output relatively abstract format document.

[0092] UI processor 932 accepts an input in a relatively abstract format such as IDML and resolves the scriptlet elements (i.e. dynamic IDML tags). In one embodiment, UI processor 932 also handles JSP taglibs and may support, for example, JSP 1.2 template tag libraries.

[0093] XSLT processor 934, given an input in a relatively abstract format, dynamically builds a list of XSLT references for the XML stylesheet. It then performs a transformation on the data to the desired client platform specification. XSLT processor 934 finds primitives paths, builds XSLT references using primitive paths and runs the relatively abstract format with references through the XSLT transformer.

[0094] According to embodiments of the present invention, the web tier 706
includes Java objects that act as external interfaces for processing and validating the elements in the relatively abstract format. In one embodiment where the relatively abstract format is IDML, the Java objects include, but are not limited to, an IDMLActionProcessor, an IDMLPreProcessor, an IDMLProcessor, an IDMLReferenceProcessor and IDMLXSLTProcessor. Functions of these Java objects are described below. Details about each Java object described below may be found in Appendix A. In addition, valid IO/expected behavior for each of the Java objects is shown in Appendices B through F, respectively.

[0095] The IDML Action Processor parses IDML markup and returns back the valid IDML link used for action transitions from page to page or other content resource (i.e. moving from one IDML page to the next, similar to a hyperlink). This processor essentially parses out a defined link location for an IDML Action markup piece.

[0096] The IDML PreProcessor processes the IDML markup and performs 1) recursed IDML unraveling and 2) Resolution of primitive paths, copy text and rendering resource paths. The output returned from this processing call is then contained in a processor result whose processed status is true.

[0097] The IDML Processor parses IDML markup and resolves the dynamic content markup tags contained within the IDML. This is relevant when using JSP tags within the IDML. This processor is fundamental to displaying dynamically generated pages filled with content.

[0098] The IDML Reference processor parses IDML markup and recurses/resolves nested IDML references from the source IDML document. The end output should be a fully recursed IDML document without any references to other UI elements of IDML.

[0099] The IDML XSLT Processor processes the IDML markup and transforms the IDML markup to the corresponding rendering target type, such as, but not limited to, HTML, cHTML and WAP. If the transaction request is of a stateless nature, ideally, the transformation templates should be cached. The output returned from this processing call is then contained in a processor result whose processed status is true.

[0100] Data service layer 704 will now be described. FIG. 11 shows a simplified block diagram of a system 1100 showing a relation of data service layer 704 to web tier 706 and database 702 on the server side and client NED types 1108, 1110, 1112 and .Net client tool 1114 on the client side.

[0101] Object bridge layer 1102 relates data tables to objects and acts as a mapping tool that automatically implements object persistence to database 702. SOAP interface 1106 allows exchanges of information over the Internet based on the XML standard. SOAP invokes methods using XML and HTTP, allowing applications to directly communicate with one another over the Internet by allowing objects created using various different languages to communicate with one another.

[0102] EJB schema domain managers 1104 provide standardized logic to different application servers based on an Enterprise Java Beans ("EJB") specification. An EJB receives data from client applications running on the client NED for processing and retrieves data from database 702 to be sent back to the client applications running on the client NED. Data is retrieved from the database 702 in an IDML format and is converted by the rendering group in the web tier 706 into the particular client language. Data service layer 704 includes EJBs for performing various functions. A non-limiting list of EJBs included in data service layer 704, along with their attributes, roles, public methods and various other parameters are shown in Tables 1-16 below.

1TABLE 1
Identifier COM-01
Defining Quality The Asset manager is an EJB can create, remove and update Assets and associated asset attributes. Name Asset Manager EJB. Attributes Handling of logical representations of physical files, handling of asset-attributes (metadata for asset records). Behaviors a. Create an asset b. Update an asset c. Remove an asset d. Retrieve an asset e. Retrieve all assets f. Add an attribute to a given asset g. Remove an attribute from a given asset h. Update an attribute from a given asset i. Retrieve all attributes from a given asset j. Find an asset attribute by name Public Methods a. createItem(Asset)--return: Asset b. updateItem(Asset)--return: Asset c. removeItem(Asset)--return: void d. getItem(Integer asset_id)--return: Asset e. getAllItems()--return: Asset array, or null f. addAssociatedAttribute(Asset, AssetAttribute)-- return: Asset, or null g. removeAssociatedAttribute(Asset, AssetAttribute)--return: Asset, or null h. updateAssociatedAttribute(Asset, AssetAttribute)--return: Asset, or null i. findAssociatedAttributeByName(Asset, String asset_name)--return: AssetAttribute, or null j. getAllAssociatedAttributes(Asset)--return: AssetAttribute array, or null Relationships None. Roles a. Service Asset management requests (locally) b. Service Asset Attribute management requests (locally) c. Service Asset management requests (remotely through SOAP) d. Service Asset Attribute management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0103]

2TABLE 2
Identifier COM-02
Defining Quality The Logical Asset manager EJB can create, remove and update Logical Assets and retrieve associated metadata. Name Logical Asset Manager EJB. Attributes Handling of logical group or individual representations of user associated assets, handling of logical asset metadata. Behaviors a. Create a logical asset d. Update a logical asset e. Remove a logical asset f. Retrieve a logical asset g. Retrieve all logical assets h. Retrieve a logical asset by given name i. Retrieve all logical assets by given asset j. Retrieve all associated metadata from a logical asset k. Retrieve all associated assets from a logical asset Public Methods a. createItem(LogicalAsset)--return: LogicalAsset b. updateItem(LogicalAsset)--return: LogicalAsset c. removeItem(LogicalAsset)--return: void d. getItem(Integer logical_asset_id)--return: LogicalAsset e. getAllItems()--return: LogicalAsset array, or null f. findItemByAsset(Asset)--return: LogicalAsset array, or null g. getAllAssociatedMetadata(LogicalAsset)--return: Metadata array, or null h. getAllAssociatedAssets(LogicalAsset)--return: Asset Array, or null Relationships None. Roles a. Service Logical Asset management requests (locally) b. Service Logical Asset management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0104]

3TABLE 3
Identifier COM-03
Defining Quality The Metadata manager EJB can create, remove and update a Metadata item. Metadata can be associated with Logical Assets. Name Metadata Manager EJB. Attributes Handling of metadata, that may describe folders/ groups associated with logical assets. Metadata usually is, but does not have to be associated with logical assets. Behaviors a. Create a metadata item b. Update a metadata item c. Remove a metadata item d. Retrieve a metadata item e. Retrieve all metadata items f. Retrieve a metadata item by given metadata type g. Retrieve a metadata item by given value Public Methods a. createItem(Metadata) return: Metadata b. updateItem(Metadata)--return: Metadata c. removeItem(Metadata)--return: void d. getItem(Integer metadata_id)--return: Metadata e. getAllItems()--return: Metadata array, or null f. findItemByType(Metadata)--return: Metadata array, or null g. findItemByValue(String)--retu- rn: Metadata array, or null Relationships None. Roles a. Service Metadata management requests (locally) b. Service Metadata management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0105]

4TABLE 4
Identifier COM-04
Defining Quality The Metadata Type manager is an EJB that can create, remove and update Metadata types. Name Metadata Type Manager EJB. Attributes Handling of metadata types, that may describe categories of metadata. Behaviors a. Create a metadata type item b. Update a metadata type item d. Remove a metadata type item e. Retrieve a metadata type item f. Retrieve all metadata type items g. Retrieve a metadata type item by given name Public Methods a. createItem(Metadata Type) return: Metadata Type b. updateItem(Metadata Type)--return: Metadata Type c. removeItem(Metadata Type)--return: void d. getItem(Integer metadata_type_id)--return: Metadata Type e. getAllItems()--return: Metadata Type array, or null f. findItemByName(String)--return: Metadata Type, or null Relationships None. Roles a. Service Metadata Type management requests (locally) b. Service Metadata Type management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0106]

5TABLE 5
Identifier COM-05
Defining Quality The country manager EJB can create, remove and update a country record, Name Country Manager EJB. Attributes Handling of country record management. Behaviors a. Create a country record b. Update a country record c. Remove a country record d. Retrieve a country record e. Retrieve all country records f. Retrieve a country record by given name g. Retrieve a country record by given country code Public Methods a. createItem(Country) return: Country b. updateItem(Country)--retur- n: Country c. removeItem(Country)--return: void d. getItem(Integer country_id)--return: Country e. getAllItems()--return: Country array, or null f. findItemByName(String)--return: Country, or null g. findItemByCode(String)--return: Country, or null Relationships None. Roles a. Service Country management requests (locally) b. Service Country management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0107]

6TABLE 6
Identifier COM-06
Defining Quality The File manager EJB can create, remove and update a File item. Name File Manager EJB. Attributes Handling of records representing physical files. Behaviors a. Create a file item b. Update a file item c. Remove a file item d. Retrieve a file item e. Retrieve all file items f. Retrieve a file item by a given name g. Retrieve a file item by a given name and path h. Retrieve a file item by a given path Public Methods a. createItem(File) return: File b. updateItem(File)--return: File c. removeItem(File)--return: void d. getItem(Integer file_id)--return: File e. getAllItems()--return: File array, or null f. findItemByName(String)--return: File array, or null g. findItemByPath(String)--return: File array, or null h. findItemByNameAndPath(String, String)--return: File, or null Relationships None. Roles a. Service File management requests (locally) b. Service File management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0108]

7TABLE 7
Identifier COM-07
Defining Quality The File extension manager EJB can create, remove and update a FileType and the associated extension. Name File Extension Manager EJB. Attributes Handling of file types and associated extensions. Behaviors a. Create a file type item b. Update a file type item c. Remove a file type item d. Retrieve a file type item e. Retrieve all file type items f. Retrieve a file item by a given name g. Retrieve a file item by a given file extension h. Add a file extension i. Add a collection of file extensions j. Retrieve file extensions k. Remove a file extension l. Remove a collection of file extensions Public Methods a. createItem(FileType) return: FileType b. updateItem(FileType)--return: FileType c. removeItem(FileType)--r- eturn: void d. getItem(Integer file_type_id)--return: FileType e. getAllItems()--return: Filetype array, or null f. findItemByName(String)--return: FileType, or null g. findItemByExtension(String)--return: FileType array, or null h. addFileExtension(FileType, String)--return: FileType, or null i. addFileExtensions(FileType, String array)-- return: FileType, or null j. getFileExtensions(FileType)--return: FileExtension array, or null k. removeFileExtension(File- Type, String)--return: FileType, or null l. removeFileExtensions(FileType, String array)-- return: FileType, or null Relationships None. Roles a. Service FileType management requests (locally) b. Service FileExtension management requests (locally) c. Service FileType management requests (remotely through SOAP) d. Service FileExtension management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0109]

8TABLE 8
Identifier COM-08
Defining Quality The User manager EJB can create, remove and update a user record. Name User Manager EJB. Attributes Handling of user records. Behaviors a. Create a user account item b. Update a user account item c. Remove a user account item d. Retrieve a user account item e. Retrieve all user account items f. Retrieve a user account item by login name g. Retreive a user account password hash a given login name and hash type Public Methods a. createItem(UserAccount) return: UserAccount b. updateItem(UserAccount)--return: UserAccount c. removeItem(UserAccount)--return: void d. getItem(Integer user_account_id)--return: UserAccount e. getAllItems()--return: UserAccount array, or null f. findItemByLogin(String)--return: UserAccount array, or null g. findPasswordHashByLogin(String, String)-- return: String, or null Relationships None. Roles a. Service User management requests (locally) b. Service User management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0110]

9TABLE 9
Identifier COM-09
Defining Quality The UI Copy manager EJB can create, remove and update a UICopy record. UICopy records contain actual text content. Name UI Copy Manager EJB. Attributes Handling of UI Copy records. Behaviors a. Create a UICopy record b. Update a UICopy record c. Remove a UICopy record d. Retrieve a UICopy record e. Retrieve all UICopy records f. Retrieve a UICopy record by given name g. Retrieve a UICopyText record by given name and renderer type and language Public Methods a. createItem(UICopy) return: UICopy b. updateItem(UICopy)--return: UICopy c. removeItem(UICopy)--return: void d. getItem(Integer ui_copy_id)--return: UICopy e. getAllItems()--return: UICopy array, or null f. findItemByName(String)--return: UICopy array, or null g. findUICopyTextItemByNameAndRendererType- AndLanguage(String, RendererType, Language)--return: UICopyText, or null. Relationships None. Roles a. Service UICopy management requests (locally) b. Service UICopy management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0111]

10TABLE 10
Identifier COM-10
Defining Quality The Renderer Resource manager EJB can create, remove and update a RendererResource record. A RendererResource record specifies resource files with specific renderer types. Name Renderer Resource Manager EJB. Attributes Handling of Renderer Resource records. Behaviors a. Create a Renderer Resource record b. Update a Renderer Resource record c. Remove a Renderer Resource record d. Retrieve a Renderer Resource record e. Retrieve all Renderer Resource records f. Retrieve a Renderer Resource record by given name g. Retrieve a Renderer Resource File record by given name and renderer type and language Public Methods a. createItem(RendererResource) return: RendererResource b. updateItem(RendererResource)- --return: RendererResource c. removeItem(RendererResource- )--return: void d. getItem(Integer renderer_resource_id)-- return: RendererResource e. getAllItems()--return: RendererResource array, or null f. findItemByName(String)--return: RendererResource array, or null g. findResourceFileItemByNameAndRendererType- AndLanguage(String, RendererType, Language)--return: RenderingResourceFile, or null. Relationships None. Roles a. Service Rendering Resource management requests (locally) b. Service Rendering Resource management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0112]

11TABLE 11
Identifier COM-11
Defining Quality The Renderer Primitive manager EJB can create, remove and update a RendererPrimitive item. A RendererPrimitive item specifies primitive files with specific renderer types. Name Renderer Primitive Manager EJB. Attributes Handling of Renderer Primitive records. Behaviors a. Create a Renderer Primitive record b. Update a Renderer Primitive record c. Remove a Renderer Primitive record d. Retrieve a Renderer Primitive record e. Retrieve all Renderer Primitive records f. Retrieve a Renderer Primitive record by given name g. Retrieve a Renderer Primitive File record by given name and renderer type Public Methods a. createItem(RendererPrimitive) return: RendererPrimitive b. updateItem(RendererPrimitiv- e)--return: RendererPrimitive c. removeItem(RendererPrimi- tive)--return: void d. getItem(Integer renderer_primitive_id)--ret- urn: RendererPrimitive e. getAllItems()--return: RendererPrimitive array, or null f. findItemByName(String)--return: RendererPrimitive array, or null g. findResourceFileItemByNameAndRendererType (String, RendererType)--return: RenderingPrimitiveFile, or null. Relationships None. Roles a. Service Rendering Primitive management requests (locally) b. Service Rendering Primitive management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0113]

12TABLE 12
Identifier COM-12
Defining Quality The Renderer Type manager EJB can create, remove and update a RendererType item. A RendererType item specifies primitive files with specific renderer types. Name Renderer Type Manager EJB. Attributes Handling of Renderer Type records. Behaviors a. Create a Renderer Type record b. Update a Renderer Type record c. Remove a Renderer Type record d. Retrieve a Renderer Type record e. Retrieve all Renderer Type records f. Retrieve a Renderer Type record by given name Public Methods a. createItem(RendererType) return: RendererType b. updateItem(RendererType)--return: RendererType c. removeItem(RendererType)--return: void d. getItem(Integer renderer_type_id)--return: RendererType e. getAllItems()--return: RendererType array, or null f. findItemByName(String)--return: RendererType array, or null Relationships None. Roles a. Service Rendering Type management requests (locally) b. Service Rendering Type management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0114]

13TABLE 13
Identifier COM-13
Defining Quality The Language manager EJB can create, remove and update a Language item. A Language item specifies language types. Name Language Manager EJB. Attributes Handling of Language records. Behaviors a. Create a Language record b. Update a Language record c. Remove a Language record d. Retrieve a Language record e. Retrieve all Language records f. Retrieve a Language record by given name Public Methods a. createItem(Language) return: Language b. updateItem(Language)--re- turn: Language c. removeItem(RendererType)--return: void d. getItem(Integer language_id)--return: Language e. getAllItems()--return: Language array, or null f. findItemByName(String)--return: Language array, or null Relationships None. Roles g. Service Language management requests (locally) h. Service Language management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP i. Idle Constraints None. Relates To n/a

[0115]

14TABLE 14
Identifier COM-14
Defining Quality The IDML UI manager EJB can create, remove and update a IDMLUI item. An IDML UI item contains unparsed IDML code chunks. Name IDML UI Manager EJB. Attributes Handling of IDMLUI records. Behaviors a. Create an IDML UI record b. Update an IDML UI record c. Remove an IDML UI record e. Retrieve an IDML UI record f. Retrieve all IDML UI records g. Retrieve an IDML UI record by given name Public Methods a. createItem(IDMLUI) return: IDMLUI b. updateItem(IDMLUI)--return: Language c. removeItem(IDMLUI)--return: void d. getItem(Integer idml_ui_id)--return: IDMLUI e. getAllItems()--return: IDMLUI array, or null f. findItemByName(String)--return: IDMLUI array, or null Relationships None. Roles a. Service IDML UI management requests (locally) b. Service IDML UI management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0116]

15TABLE 15
Identifier COM-15
Defining Quality The IDML Scriptlet manager EJB can create, remove and update a IDML Scriptlet item. An IDML Scriptlet item contains unparsed IDML scriptlet code chunks. Name IDML Scriptlet Manager EJB. Attributes Handling of IDML Scriptlet records. Behaviors a. Create an IDML Scriptlet record b. Update an IDML Scriptlet record c. Remove an IDML Scriptlet record d. Retrieve an IDML Scriptlet record e. Retrieve all IDML Scriptlet records f. Retrieve an IDML Scriptlet record by given name Public Methods a. createItem(IDMLScriptlet) return: IDMLScriptlet b. updateItem(IDMLScriptlet)--return: IDMLScriptlet c. removeItem(IDMLScriptlet)--return: void d. getItem(Integer idml_scriptlet_id)--return: IDMLScriptlet e. getAllItems()--return: IDMLScriptlet array, or null f. findItemByName(String)--return: IDMLScriptlet array, or null Relationships None. Roles a. Service IDML Scriptlet management requests (locally) b. Service IDMLScriptlet management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0117]

16TABLE 16
Identifier COM-16
Defining Quality The IDML Action manager EJB can create, remove and update a IDML Action item. An IDML Action item contains unparsed IDML Action code chunks. Name IDML Action Manager EJB. Attributes Handling of IDML Action records. Behaviors a. Create an IDML Action record b. Update an IDML Action record c. Remove an IDML Action record d. Retrieve an IDML Action record e. Retrieve all IDML Action records f. Retrieve an IDML Action record by given name Public Methods a. createItem(IDMLAction) return: IDMLAction b. updateItem(IDMLAction)--return: IDMLAction c. removeItem(IDMLAction)--return: void d. getItem(Integer idml_action_id)--return: IDMLAction e. getAllItems()--return: IDMLAction array, or null f. findItemByName(String)--return: IDMLAction array, or null Relationships None. Roles a. Service IDML Action management requests (locally) b. Service IDML Action management requests (remotely through SOAP) State Groups a. Active usage though local interface b. Active usage though SOAP c. Idle Constraints None. Relates To n/a

[0118] According to embodiments of the present invention, the data service layer 704 includes EJBs that function as an external interface. In one embodiment, the external interface EJBs include, but are not limited to, CountryManager, FileManager, FileTypeManager, IDMLActionManager, IDMLUIManager, LanguageManager, RendererTypeManager, RenderingPrimitiveManager, RenderingResourceManager and UICopyManager. Functions of these EJBs are described below. Details about each EJB described below may be found in Appendix G.

[0119] The Country Manager EJB interface manages countries used by the platform services runtime. Specifically, the country manager can create, remove, retrieve, query and update countries within the data service layer.

[0120] The File Manager EJB interface manages files used by the platform services runtime. Specifically, the file manager can create, remove, retrieve, query and update soft file references (with pointers to the actual file content) within the data service layer.

[0121] The File Type Manager creates a new file type item given a registered file type name and extension.

[0122] The IDML Action Manager EJB interface manages UI action items used by the platform services runtime. Specifically, the action manager can create, remove, retrieve, query and update IDML action elements for handling "clicks" such as, but not limited to, links within the presentation layer.

[0123] The IDML UI Manager EJB interface manages UI page items used by the platform services runtime. Specifically, the UI manager can create, remove, retrieve, query and update IDML UI page elements for rendering pages or other content resources within a presentation layer.

[0124] The Language Manager EJB interface manages languages used by the platform services runtime. Specifically, the UI manager can create, remove, retrieve, query and update registered languages for rendering pages or other content resources in a presentation layer or, in some embodiments, setting user preferences.

[0125] The Renderer Type Manager EJB interface manages target renderer types used to define the different rendering views used by the platform services runtime. Specifically, the renderer type manager can create, remove, retrieve, query and update registered renderer types for defining the possible views via a presentation layer.

[0126] The Rendering Primitive Manager EJB interface manages IDML primitives used to composite pages used by the IDML UI for the platform services runtime. Specifically, the rendering primitive manager can create, remove, retrieve, query and update registered renderer primitives that are used to implicitly render pages or other content resources for the presentation layer.

[0127] The Rendering Resource Manager EJB interface manages IDML resources used to composite pages (including, but not limited to, gifs and audio files) used by the IDML UI for the platform services runtime. Specifically, the rendering resource manager can create, remove, retrieve, query and update registered renderer resources that are used to implicitly display external resources for pages or other content resources for a presentation layer.

[0128] The UI Copy Manager EJB interface manages text copy used in compositing pages (i.e. written text for the language) used by the IDML UI for the platform services runtime. Specifically, the UI copy manager can create, remove, retrieve, query and update registered UI copy text that are used to display written content for pages or other content resources for the presentation layer.

[0129] Database 702 will now be described. According to embodiments of the present invention, rendering elements, action elements and UI elements, and copy may be stored in a database such that they are accessible to client applications. In one embodiment, the database is an Oracle.TM. 8I database. However, other suitable databases such as, but not limited to, Oracle 9i, FoxPro, DB2, Informix, Sybase, Access, mySQL, and MS SQL may also be used. An exemplary schema of the database for storing rendering elements, action elements and UI elements, and copy, according to one embodiment of the present invention, is shown in FIG. 12.

[0130] FIG. 13 shows a simplified block diagram of a mark-up language ("ML") rendering group 1302 within web tier 706, along with database 702
and data service layer 704, according to embodiments of the present invention. ML rendering group 1302 may be any ML rendering group, including HTML rendering group 516 shown in FIG. 5.

[0131] According to embodiments of the present invention, ML renderer 1304
performs functions including, but not limited to, replacing IDML collection styles with ML page styles; embedding ML templates within a given style based on incoming IDML UI constructs and actions; performing one-to-one substitution of keyed variables from IDML to ML templates; maintaining a data "snapshot" of the current page for rapid incremental updates; recursively requesting preprocessed IDML from web messaging servlets 1306, which in turn use the state maintenance/preprocessor beans 1308; fetching non-IDML primitives and collections (such as, but not limited to, SWF and .jpg) via the web messaging servlets 1306 using paths specified in returned, preprocessed IDML; and outputting final ML pages (such as, but not limited to, HTML, WML and cHTML).

[0132] According to embodiments of the present invention, the state maintenance/preprocessor beans 1308 perform functions including, but not limited to, initially tracking only selected rendering platforms and localization settings; on each request received from ML rendering group 1302 via the web messaging servlets 1306, using the data service layer 704 API to retrieve unmodified IDML, primitives and collections (ASCII data), paths to file-based binary primitives and language specific text (ASCII copy); compositing paths and text copy into IDML; replacing IDML statement "{%NAMED_DB_OBJECT:NAMED_ELEMENT%}" with actual database content; and passing modified IDML and other ASCII data back to the ML rendering group 1302 via the web messaging servlets 1306.

[0133] According to embodiments of the present invention, ML action handler 1310 performs functions including, but not limited to, accepting input from mark-up languages (such as, but not limited to, HTML, WML and cHTML); retrieving a selected action or actions through the data service layer 704 API via the web messaging servlets 1306, which in turn use the state maintenance/preprocessor beans 1308; scheduling actions to the ML renderer 1304; and on completion of actions, sending an update command to ML renderer 1304, signaling that a render to the specified mark-up language should be performed, resulting in a viewable ML page 1312.

[0134] FIG. 14 shows a simplified block diagram of a Flash rendering group 1402 which may be a self-contained client-side renderer, along with database 702, data service layer 704 and web tier 706, according to embodiments of the present invention.

[0135] According to embodiments of the present invention, Flash renderer 1404 performs functions including, but not limited to, recursively requesting preprocessed IDML from web messaging servlets 1306, which in turn uses state maintenance/preprocessor beans 1308; using web messaging servlets 1306 to fetch non-IDML primitives and collections (such as, but not limited to, SWF, and .jpg) using paths specified in returned preprocessed IDML; and outputting a Flash page.

[0136] According to embodiments of the present invention, Flash action handler 1410 performs functions including, but not limited to, accepting input from Flash; retrieving a selected action or actions through the data service layer 704 via web messaging servlets 1306, which in turn use state maintenance/preprocessor beans 1308; handling actions from within the Flash rendering group 1402; triggering updates of Flash pages through the Flash renderer 1404. According to embodiments of the present invention, Flash action handler 1410 is located within the Flash rendering group 1402 and is thus not a Java servlet.

[0137] As described above, systems and methods for platform and language-independent delivery of page-based content transform content in a relatively abstract format into multiple platform formats in client-side applications' user interfaces in multiple human languages. In one embodiment, the relatively abstract format may be IDML.

[0138] The following describes the syntax of IDML and its allowable use, according to embodiments of the present invention. FIG. 15 shows an example IDML document structure, according to embodiments of the present invention. An IDML document may always start with a required <idml> tag. The IDML tag has no allowable attributes. Allowable nested tags are the UI tag. An example of a IDML tag is shown below:

[0139] <idml>

[0140] . . .

[0141] . . .

[0142] </idml>

[0143] After the IDML tag, the <ui> tag is required. The UI tag has no allowable attributes. Allowable nested tags are primitive, collection, resource, text, list_wrapper and primitive_list. An example of a UI tag is shown below:

17
<idml> <ui> . . . </ui> </idml>

[0144] A primitive tag is used to parameterize any primitives that are going to be included in the page. Primitives can only contain resources and text. Required attributes of the primitive tag are: name (the business name of the primitive) and render_location (the render location that the primitive will be placed in). Allowable attributes of the primitive tag are: idml_id (the name or identification("ID") of the IDML element which further defines this primitive) and action_id (the name or ID of the action associated with this primitive) and custom attributes (any other attributes used specifically by this primitive). Allowable nested tags are: text (copy text used by this primitive) and resource (rendering resource (graphical element) used by this primitive). An example of a primitive tag is shown below:

18
<idml> <ui> <primitive name = "page_header" render_location = "header_area"> . . . </primitive> </ui> </idml>

[0145] A resource tag is used to specify any rendering resources that are going to be included in the page. Required attributes of the resource tag are: name (the business name of the resource) and render_location (the render location that the resource will be placed in). The resource tag has no allowable attributes or nested tags. An example of a resource tag is shown below:

19
<idml> <ui> <primitive name = "page_header" render_location = "header_area"> <resource name = "elmacho_header" render_location = "header_resource_area"/> </primitive> </ui> </idml>

[0146] A text tag is used to specify any copy text that is going to be included in the page. Required attributes of the text tag are: copy_id (the business name of the copy text) and render--location (the render location that the text will be placed in). The text tag has no allowable attributes or nested tags. An example of a text tag is shown below:

20
<idml> <ui> <primitive name = "page_header" render_location = "header_area"> <resource name = "elmacho_header" render_location = "header_resource_area"/> <text copy_id = "elmacho_title" render_location = "header_title_area"/> </primitive> </ui> </idml>

[0147] A collection tag is used to parameterize any collections that are going to be included in the page. Collections can contain primitives or other collections, as well as resources and text. Required attributes of the collection tag are: name (the business name of the primitive) and render_location (the render location that the collection will be placed in). Allowable attributes of the collection tag are: idml_id (the name or ID of the IDML element which further defines this primitive), action_id (the name or ID of the action associated with this primitive) and custom attributes (any other attributes used specifically by this collection). Allowable nested tags are: text (copy text used by this primitive), resource (rendering resource (graphical element) used by this primitive), collection (a collection contained within this collection) and primitive (a primitive contained within this collection). An example of a collection tag is shown below:

21
<idml> <ui> <collection name = "main_page_template" render_location = "main_area"> <primitive name = "page_header" render_location = "header_area"> . . . </primitive> <primitive name = "page_footer" render_location = "footer_area"> . . . </primitive> </collection> </ui> </idml>

[0148] A list_wrapper tag is used to wrap the primitive_list tag. This is due to the fact that the primitive_list tag has no allowable custom attributes. As such, the custom attributes can be included in the list wrapper. The list_wrapper tag has no required attributes. Allowable attributes are: custom attributes (any other attributes used specifically by this list). Allowable nested tags are: primitive_list (the primitive list which is wrapped by this list wrapper). An example of a list_wrapper tag is shown below:

22
<idml> <ui> <list_wrapper x_offset = "20" y_offset = "30"> <primitive_list type = "array"> . . . </primitive_list> </list_wrapper> </ui> </idml>

[0149] A primitive_list is used to parameterize collections that are iterative in nature such as menus or other lists. Required attributes of the primitive_list are: type="array". For flash compatibility, the type="array" attribute must be included. The primitive_list has no allowable attributes. Allowable nested tags are: item (lists can contain many items). An example of a primitive_list is shown below:

23
<idml> <ui> <list_wrapper x_offset = "20" y_offset = "30"> <primitive_list type = "array"> <item> . . . </item> <item> . . . </item> </primitive_list> </list_wrapper> </ui> </idml>

[0150] An item tag is used to wrap the individual items in a primitive list. The item tag has no required or allowable attributes. Allowable nested tags are: primitive, collection, list_wrapper and primitive_list. An example of an item tag is shown below:

24
<idml> <ui> <list_wrapper x_offset = "20" y offset = "30"> <primitive_list type = "array"> <item> <primitive name = "button" render_location = "button_area"> <text copy_id = "drama_button"/> </primitive> </item> <item> <primitive name = "button" render_location = "button_area"> <text copy_id = "action_button"/> </primitive> </item> </primitive_list> </list_wrapper> </ui> </idml>

[0151] One of the IDML syntax examples shown above is repeated below, along with a exemplary data tables 17 and 18, which may be saved, for example in a data source such as a database. Tables 17 and 18 illustrate a correspondence between the IDML code and the data tables stored in the data source.

25
<idml> <ui> <primitive name = "page_header" render_location = "header_area"> <resource name = "elmacho_header" render_location = "header_resource_area"/> <text copy_id = "elmacho_title" render_location = "header_title_area"/> </primitive> </ui> </idml>

[0152]

26TABLE 17
(Copy Grid) HTML Flash cHTML English "elmacho_title" "elmacho_title" "elmacho_title" Spanish .................... ..................... ..................... French ..................... ..................... .....................

[0153]

27TABLE 18
(Primitive Grid) HTML "page_header"_HTML.XSLT c