WO2002103553A2 - Tool for web authoring assistance - Google Patents

Abstract

A method of automatically generating display formatting instructions for a plurality of documents on a server for displaying the plurality of documents on a client during a run-time interval, the server having a plurality of formatting controls and a file with a first set of formatting instructions containing a plurality of references, each reference indicating one of the plurality of formatting controls and one of the plurality of documents, said method comprising: (A) processing said file to locate each of the plurality of references to form a tree; (B) executing one of the plurality of formatting controls according to one of the plurality of references to create a second set of formatting instructions based on said indicated document in said one of the plurality of references; wherein each of the plurality of formatting controls indicated in the plurality of references is executed before the run-time interval.

Description

TOOL FOR EB AUTHORING ASSISTANCE

The present invention is directed towards a tool for web page authoring assistance, specifically, a tool for automatically generating display formatting code for a web page.

With the proliferation of the World Wide Web (WWW) , rapid design and generation of web pages is becoming a necessity. Web pages need to be created quickly but retain complexity and flexibility. There are a number of tools for web page authoring that assist in the creation of web pages by automatically generating markup code, such as Hypertext Markup Language (HTML) , based on input parameters . Markup code conveys instructions on how to present and display data' identified by the code. These tools allow content of the web page to be altered without necessitating re-creation of the entire page. This is often accomplished by storing changing content separately from the web page and including a tag in the markup code that refers to the location of the changing content. The web page can then be processed according to a control specified by the tag and markup created and incorporated for the separately stored changing content .

Microsoft offers ActiveX Design Time Controls (DTCs) that may be inserted into a markup code file and processed during design of the page, before run-time, see U.S. Patent 6,025,119. However, DTC processing is limited to the editor in which the markup code file is created, often located on an authoring client. Many operations may be performed more efficiently by separating authoring from processing, such that processing need not occur in a specified editor on the client.

DTCs are based on markup code comments, which are used to enclose the controls. Unfortunately, markup code comments cannot be nested within each other, thus limiting the use of DTCs in the creation of page layouts. That is, a page layout cannot be controlled by using a DTC and embedding other DTCs in it. To provide page layout functionality, a separate tool must be used in combination with DTCs .

DTCs have the drawback that their use is limited to Microsoft platforms. JavaServer Pages (JSP) taglibs on the other hand provide similar functionality but as they are based on the Java language they are not platform specific. However, taglibs are executed only at request time, necessitating that a taglib processor be part of a web application server. Further, since taglibs generate dynamic contents there is an increase in server processing loads . The present invention provides a method of automatically generating display formatting for a plurality of documents on a server as claimed in claim 1. The invention provides a corresponding server system of claim 9 and computer program product of claim 10.

The invention allows generating display formatting code for a web page at various stages during the code lifecycle and provides a method for web page authoring assistance that can be used for web page layout .

This allows sources of content for a web page to be separated from the web page and provides quick, automatic updating of the web page in response to a change in the sources . The controls of the present invention can be imbedded in each other, allowing complex web pages to be easily created.

The present invention will be described in conjunction with the drawings in which:

Fig. 1 is schematic diagram depicting a computing environment according to embodiments of the present invention;

Fig. 2 is a flow diagram depicting a method for assisting web authoring by automatically generating markup code from content sources;

Fig. 3 is a flow diagram depicting the step of .generating markup code from Fig. 2 in greater detail;

Fig. 4 is a system diagram depicting a system for assisting web authoring by automatically generating markup code from content sources ; and

Fig. 5 is a system architecture diagram depicting the WAC processor of Fig. 4.

Fig. 1 and the associated description represent an example of a suitable computing environment in which the present invention may be implemented. While the embodiments of the invention will be described in the general context of computer-executable instruction of a computer program that runs on a personal computer, the present invention can also be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures and the like that perform particular tasks or implement particular abstract data types. Further,- the present invention can also be implemented using other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and distributed computing environments where program modules may be located in both local and remote memory storage devices .

With reference to Fig. 1, the present invention may be implemented within a general purpose computing device in the form of a conventional personal computer 200, including a processing unit 210, a system memory 220, and a system bus 230 that couples various system components including the system memory 200 to the processing unit 210. The system memory 200 includes read only memory (ROM) 240 and random access memory (RAM) 250.

A basic input/output system 260 (BIOS) , containing the basic routines that help to transfer information between elements within the personal computer 200 (e.g. during start-up) is stored in ROM 240. The personal computer 200 further includes a hard disk drive 270 for reading from and writing to a hard disk (not shown) , a magnetic disk drive 280 for reading from or writing to a removable magnetic disk 290, and an optical disk drive 291 for reading from or writing to a removable optical disk 292 such as a CD ROM or other optical media, all of which are connected to the system bus 230 by respective interfaces 292, 293, 294. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 200. Although the exemplary environment described herein employs certain disks, it should be appreciated by those skilled in the art that other types of computer readable media for storing data may also be employed.

A number of program modules may be stored on the disks 290, 292, ROM 240 or RAM 250, including an operating system 295, one or more application programs 296, other program modules 297, and program data 298. Commands and information may be entered into the personal computer 200 through input devices (e.g. a keyboard 201, pointing device 202, a microphone, joystick, etc.) . These input devices may be connected to the processing unit 210 through a serial port interface 206, a parallel port, game port or a universal serial bus (USB) . A monitor 207 or other type of display device is also connected to the system bus 230 via an interface, such as a video adapter 208. The personal computer 200 may operate in a networked environment using logical connections to one or more remote computers 209, such as another personal computer, a server, a router, a network PC, a peer device or other common network node. The logical connections depicted in FIG. 1 include a local area network (LAN) 212 and a wide area network (WAN) 213. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the personal computer 200 is connected to the local network 212 through a network interface or adapter 214. When used in a WAN networking environment, the personal computer 200 typically includes a modem 215 connected to the system bus 230 via the serial port interface 206 or other means for establishing a communications over the wide area network 213, such as the Internet. The operations of the present invention may be distributed between the two computers 200, 209, such that one acts as a server and the other as a client (see Fig. 4) . Operations of the present invention for each computer 200, 209 (client and server) may be stored in RAM 250 of each computer 200, 209 as application programs 296, other program modules 297, or on one of the disks 270, 280, 291. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Fig. 2 is a flow diagram depicting a method 10 for assisting web authoring by automatically generating markup code from content sources.

The term markup code refers to any code used in the formatting and display of web pages and can be used interchangeably with the term display formatting instructions . Markup code can be in such markup languages as HTML, Java Server Pages (JSP) , Active Server Pages (ASP) , Extensible Markup Language (XML), etc. Complex web pages are created by the method 10 automatically generating markup code based on simple input parameters. The method 10 provides a way to incorporate content from sources that can be separated from the web pages by referencing these content sources in the underlying code for the web page and processing that code prior to display execution.

A first set of markup code is created in step 12 to serve as the basis for a web page. Included in this first set of markup code is a web authoring control (WAC) tag that is inserted in the code in step 14. A WAC defines the operation of formatting the^" content source for display and optionally inserting the formatted content source into a web page. The WAC tag specifies how a content source referred to in the tag is to be formatted and inserted into the first set of code. The content source referred to in the tag is part of a project containing related documents and resources to which the first set of code belongs. By setting input parameter values in the WAC tag and then executing a processor, markup code is generated for the content source to which the WAC tag refers .

Execution of a WAC produces a result that is similar to a parameterized macro .

For example, navigation controls may be added to all pages of a web site by creating a site map resource and a WAC that reads the site map and generates and inserts the navigation controls into each individual web page. That is, by inserting a WAC tag for the navigation controls content into a web page, markup code for the navigation controls may be automatically generated and added to that page . Such a result was often previously accomplished by a copy and paste action for adding the navigation controls already in markup code to each individual page.

As another example, for web page display of each record in a database table and an index page linking to these records, WACs- can be used to simplify the process of generating markup for each record and the index page . A web page with the index and a record can be created by using a pair of WACs, one for the index and another for the records. Tags for these WACs may be incorporated in a web page used for the display of the index and records .

Values of the WAC input parameters are set in the WAC tag in step 16. The creation of the first set of markup code, the insertion of the WAC tag and the parameter value setting (steps 12 to 16) may all be performed in a standard markup code editor.

A second set of markup code is generated in step 18 from the content source referenced by the WAC tag. The WAC defines this generation process ; how the content source is read and formatted into the markup code.

The life cycle of web page authoring has a defined set of contexts including creation, save, edit, preview, check in and publish, with the check in and publish stages possibly occurring on an authoring server. These stages in the life cycle can be used as trigger points to initiate execution of WACs, possibly on the authoring server. For example, as one document in a project changes and is checked in, all documents that are affected by this change can be reprocessed to include these changes. This allows static content to be used yet easily changed allowing WACs to be processed at any point during the life of a web page. Use of static content reduces server processing loads and allows the web page to be indexed by a search engine.

The processing of a WAC to generate markup code can occur at. various stages during the life cycle of the web page. This simplifies maintenance of the web page as it can be reprocessed when an input parameter, a resource or the entire content source is changed. In the above example for navigation controls, the web pages containing a WAC tag referencing the navigation controls source can be reprocessed when the map site changes without requiring that each individual page be manually altered.

The second set of markup code generated from the content source is incorporated into the first set of markup code in step 20. Optionally, the second set of markup code may be incorporated into a separate output file. This combined set of markup code is saved in step 22. The combined markup code is sent to a requestor upon receiving a request in step 24 for retrieval and display.

The second set of markup code can optionally be edited before incorporation into the first set of markup code. Any changes or additions made by a user at this time are marked as being user generated.

Fig. 3 is a flow diagram depicting the step of generating markup code 18 from Fig. 2 in greater detail. A WAC processor reads the first set of markup code in step 30 and locates all of the WAC tags in this code, step 32. A tree structure is formed from all of the WAC tags in the first set of markup code . Location of WACs and formation of the tree may be performed according to known techniques. For example, a WAC implemented using Java and XML can form a tree according to the Document Object Model (DOM) standard. This tree acts as a map for the first set of markup code, setting out all WACs that need to be processed and the order of their occurrence in the first set of code. For cases where WAC tags may be embedded, the tree allows for depth-first order processing of the WACs and retains relative placement of the results of the WAC processing.

In step 34 the parameters input for a specific WAC tag are passed to the WAC processor and then the WAC is executed, step 36. When multiple WACs are located in a single first set of code then steps 34 and 36 are repeated for each individual WAC. When all WACs have been executed then the results of the processing are incorporated into the first set of code, step 20.

Fig. 4 is a system diagram depicting a system 50 for assisting web authoring by automatically generating markup code from content sources 68. The system 50 depicted uses a client 54 and a server 52 where authoring of the web page occurs on the client 54 and execution of WACs occurs on the server 52.

The client 54 contains a standard markup language editor 62. The editor 62 is used in the creation of a first set of markup code 64. This first set of code 64 forms the basis for a web page. Within the first set of code 64 is a tag 66 to a WAC that specifies a content source 68 external to the first set of code 64. The content source 68 and the first set of code 64 may be part of a larger project. The WAC indicated in the tag 66 specifies how the content source 68 is to be processed and optionally incorporated into the first set of code 6 .

The client 54 may contain other development tools such as, for example, a project manager for controlling resources in a project and a build processor for processing the resources. The client 54 may also include a source code control system for storing versions of the project resources and controlling concurrent access to them.

The server 52 contains a repository for storing all of the documents' of the project to which the content source 68 and first set of code 64 belong. This repository, a web page storage device 58, receives documents related to the project from one or multiple clients 54. ^• If multiple clients 54 are sharing this data the storage device 58 may include a document control mechanism to limit editing ability of the documents to a single client 54 at a time. The documents, such as the first set of code 64, are stored in the web page storage device 58 after creation along with related documents (i.e. content sources 58) from the client 54. The server 52 also contains a publishing request processor 60 for servicing requests to view web pages stored in the storage device 58.

The server 52 has a WAC processor 56 for processing WAC tags in documents in the storage device 58 according to WAC definitions stored in a WAC definitions storage device 70. A WAC tag in a document contains a reference to a WAC identifier or name, as well as parameters providing data to the WAC to control processing. The WAC processor 56 could be invoked by a build processor in the client 54 when project documents are updated.

Each WAC definition stored in the WAC definitions storage device 70 has three components: an identifier 72, parameters 74 and control actions 76. When a WAC tag is read from the first set of code 64 saved on the server 52 for processing, the WAC identifier and parameters are stored as separate elements to be used during execution of the WAC. The identifier 72 is a unique identifier specific for a certain type of WAC. The parameters 74 include basic formatting information and may include references to other WACs . The control actions 76 generate markup according to information supplied in the parameters 7 . The markup generated by the control actions 76 is a sequence of characters inserted in the document that was referenced in the AC tag 66, the content source 68. This sequence of characters indicates how the content source 68 is to be displayed in conjunction with the display of the first set of code 64. That is, the control actions 76 translates the content source 68 into the markup language of the first set of code 64, for example, HTML, such that there can be a seamless display of the two sets of code or incorporation of the content source 68 into the first set of code 64.

The control actions 76 simplify web authoring by presenting an interface that assists in setting the parameters 74. The editor 62 on the Client side 54 may include, for example, reference to the WACs by the identifier 72 via a property sheet, with optional custom property editors. The control actions 74 can be used to automate tedious tasks, such as adding line numbers to listings or to eliminate the need for the user to be able to write complex HTML or Javascripts .

Fig. 5 is a system architecture diagram depicting the WAC processor

56 of Fig. 4. The WAC processor 56 accepts parameters that specify a document to be processed and included into a file containing the first set of code 6 . The WAC processor 56 also receives parameters pertaining to the life cycle stage of the first set of code 64 and other processing options such as whether the first set of code 64 should be updated or stripped of WAC tags before output.

A document reader 80 in the WAC processor 56 reads the first set of code 64 from the current project. As the file containing the first set of code 64 is being read the document reader 80 passes the read file to the document parser 82 where a tree structure is formed from the contents of the read file. A document updater 84 updates WACs in the parsed file . Execution of the document updater 84 can be suppressed by using an input parameter. This is useful when the file has already been updated but the WAC tags must be removed prior to publishing. The document update 84 traverses the tree and executes each WAC tagged in the tree . Each executed WAC generates markup code that can contain additional WACs that become part of the tree and are executed. The tree is traversed once in a depth-first order that corresponds to the order of the WACs in the file. The document updater 84 also extracts WAC tags from the first set of code 64 and temporarily stores the WAC identifiers and parameters from each tag.

A control loader 90 in the document updater 84 obtains the temporarily stored WAC identifier. The control loader 90 searches through the WAC definitions in the WAC definition storage device 70 to find the WAC definition having the same identifier 72 as the one that is being held. Upon finding a matching identifier the control loader 90 creates an instance of that WAC definition. WAC instances can be pooled and reused to improve performance .

A control executor 92 takes the held parameters and sets them as properties of the parameters 74 definition of the WAC instance created by the control loader 90. The control executor 92 then executes the WAC instance and creates updated markup code, such as the second set of code. The WAC instance can access project resources during its execution to obtain content from content sources stored on the server 52 or elsewhere, as referenced from the WAC tag.

A resource manager 96 in the control executor 92 provides the executing WAC instance with access to the project resources, such as content sources. The WAC instance can create, read, update and delete project resources. For example, a WAC that generates banners or navigation bars could access a site map project resource. Also, a WAC that generates pages from a database could delete the existing set of pages and then create a new set of pages .

A content merger 94 in the document updater 84 takes the updated markup code and merges it into the file. That is, the content merger 94 merges the second set of code into the first set of code 64 according to the type of code, automatically generated or user generated. These types of code are differentiated from each other to facilitate merging of the second set of code into the first 6 . User generated code is marked as being user generated and any remaining non-user generated code is presumed to be automatically generated. The second set of code is formed from new markup code, either automatically generated or user generated, whereas the first set of code 64 contains old code. Before merging the two sets of code, a correspondence is made to determine if portions of the two sets correlate; note is made of any such corresponding portions.

Old automatically generated markup code (in the first set of code 64) is removed from the file and replaced by new automatically generated markup code from the second set of code. New markup code, either automatically generated or user generated, that does not correspond with portions of the first set of code 64 is inserted into the first set 64. If the new markup code contains markup from a user, then the old markup code is checked for matching code. old user markup code may be kept over the corresponding new user markup code. This allows original user changes to the format to be retained and not overwritten during an automatic execution of WACs, for example, in response to a change in a document of the current project. Alternatively, old user code may be replaced by corresponding new user code by specifying such in the parameters . The user markup code can have name attributes that are used in the merging process to make a correspondence between the old and new user markup code.

The corresponding new user markup code can be in a different order that the older user markup code, in which case the content merger 94 module may reorder the old user markup code. This allows WACs to implement flexible page layout. For example, suppose a page layout defines a main topic and a sidebar, and the location of the sidebar is specified by a parameter of the WAC. Then when the location is changed the content merger 94 will correctly reorder the layout regions .

A control stripper 86 in the WAC processor 56 removes WAC tags from the first set of code. The WAC processor 56 normally preserves the WAC tags, but the WAC tags can optionally be removed by specifying an input parameter to the WAC processor 56 in the WAC tags. Stripping the WAC tags from the first set of code 64 can decrease the document size as well as remove sensitive parameter information, such as database passwords.

A document writer 88 in the WAC processor 56 writes the merged code to an output file. The output of the merger can either overwrite the original file or be written to a different file. The merged code may be written to a different file at publication time since control stripping may be desired. WAC processing may also occur at a single location where the server and the client functions are located on a single computer (not shown) . In this case a markup code file can be fully processed on a computer used for developing the code (i.e. WAC execution occurs on the client). After processing, the file with the first set of code can be published to a standard web server to handle display requests . The processing can be controlled by passing a context parameter as input to the WAC processor. The context parameter specifies the life cycle stage of the document (i.e. creation, maintenance, etc.) . The WAC processor, residing on the development computer, fully processes the code to prepare it for display in response to requests received by the web server.

Although the embodiments of the present invention described thus far have been processed at the time of completion of authoring, a WAC could also be processed at execution time when a request to display a web page is received.

WACs can be used to periodically automatically refresh content on web pages. For example, if a web site contains a product catalog with product information stored in a database that is updated every day, WACs can assist in updating the web pages to reflect database changes. WACs in the web pages of the web site can link to the database and be used to extract the database information into the web pages that are then published to a web server. After each update of the database the WAC processor can be used to regenerate an index page and all of the product pages from the database. The generated documents could be in HTML if no further dynamic content is included in the web page, or if additional dynamic content is needed, in JSP, for example. Using WACs to generate content that changes infrequently (i.e. can be somewhat static) reduces the amount of processing required. If JSPs are used without WACs then the database would be accessed for each page requested at execution time, resulting in slower performance and requiring more computers to maintain acceptable performance. Using WACs confines execution time processing to generating frequently changing dynamic content.

One possible implementation for the present invention is to specify WAC tags using document type definitions (DTDs) , rules that define the tags that can be used in an XML file and their valid values. The definition for a WAC could use an XML schema that specifies tags for inserting WACs into web pages, a Java library for developing WACs and a Java processor for generating code in web pages that contain WACs. The XML schema being a system of representing a data model that defines the data's element and attributes, and the relationships among the elements. The identifier 72, parameters 74, and control actions 76 could be implemented as elements, which are an XML structural construct having start and end tags and information between the tags referred to as the contents .

With such an implementation, information about execution of a WAC, such as parameter values and content source location, are contained as attributes in the WAC tag. This allows nesting of WACs such that during the execution of a first WAC, a second embedded WAC may be discovered and executed to include results thereof in the results of the first WAC execution.

The DTD for WACs specifies that all data is represented as XML attributed of WAC tags. The full implementation of a DTD for a WAC is shown in Appendix A (wac.dtd) . Since the normal behavior of web browsers is to display only HTML tags, all WAC tags are effectively hidden when the document is displayed. This use of XML therefore achieves the same effect as the use of HTML comments and allows WACS to be nested as may be desirable for creation of complex web page layouts.

For HTML or XML parsing of the first set of code, the creation of the tree produces a Document Object Model (DOM) that can be used for controlling WAC processing order.

With this possible implementation new WACs may be created by implementing Java classes. A Java class is a collection of data members and methods that define a particular object.

The invocation of an exemplary WAC based on such an implementation is shown below.

<?xml version="l .0" encoding="ISO-8859-l"?> <html> <head>

<title>Listing of source</title> <body>

<h4>Listing of source. </h4> <wac: control xmlns :wac="urn: ibm. com:wac" name="mod" class=" wac. samples. Include" > <wac :parmeters>

<wac:param name=" include" value=" /source" valuetype="ref"/> <wac:param name=" formatted" value="true"/>

<wac:param name="numbered" value="false"/> </wac : arameters> </wac .- markup> <wac : control> </body> </html>

The tag <wac:control> marks the start of the WAC tag. This tag specifies that the WAC to be used is the Java class named wac . samples . Include . This class will be executed by the WAC processor 56.

The tag <wac:parameters> marks the start of the parameters section. It specifies that the parameter named "include" has the value "/source" that is interpreted by the Include WAC to mean that the resource "source" is to be included in the HTML page. The web page does not include the contents of "source" until the WAC is processed and HTML code is generated for the contents of "source." When the web page is processed the WAC processor reads the pages and locates the WACs in it, passes them the specified parameters, executes them, and merges their output back into the web page.

For a Java implementation a control element has a name, a class and an enablement value. The name is a unique identifier for the control so that it can be referenced by other controls. The class is the name of the Java class that implements the control . The enablement value is set to determine if the control should regenerate its markup. The following is an exemplary structure for a control element. <! ELEMENT control (parameters, markup) >

<!ATTLIST control id ID #REQUIRED

Class CDATA #RΞQUIRED enabled (true | false) "true">

A control element contains a parameters element that contains the parameters that are used to set the properties and a markup element that contains the generated markup.

The parameters element contains the parameters that are used to set the control properties . The following is an exemplary structure for a parameters element .

<! ELEMENT parameters (param | paramarray) *>

The parameters element contains a param element that defines a single control property. The param element has an exemplary structure as follows .

<! ELEMENT param EMPTY>

<!ATTLIST param name CDATA #REQUIRED value CDATA #REQUIRED valuetype (data | ref j object) "data">

The param element has a property name and a property value . The param element also has a property value type that can be data (such as a number of string), URL reference or another element. If the type of property is a URL it may be absolute, or begin with a scheme such as "http:", or it may be relative. A relative URL refers to another resource in the same project.

10

The parameters element also contains a param array element, having an exemplary structure outlined below.

<! ELEMENT paramarray (paramvalue) *> 15 <!ATTLIST paramarray name CDATA #RΞQUIRED valuetype (data ] ref | object) "data">

The paramarray element defines a control index property. The param

20 array has a property name and property value type, similar to that of the param element .

The paramarray also has a paramvalue element, an exemplary structure of which is outlined below.

25

<! ELEMENT paramvalue EMPTY> <!ATTLIST paramvalue value CDATA #required>

30 The paramvalue element defines the value of an indexed property for a given index. The position of a paramvalue element in the param array element defines the index.

A markup element contains the markup generated by the control 35. element. The markup element may contain any valid non-WAC markup, as well as control and usermarkup element, either directly or indirectly. Generated markup can be changed by the user by disabling the control .element enablement value. Alternatively, the WAC tags can be striped from the generated markup . 40

A usermarkup element allows the user to insert markup in the markup . generated by a WAC. When the WAC regenerates the markup the contents of the usermarkup element are preserved. The usermarkup element has a name identifying the element that identifies its purpose. The usermarkup 45 element may contain any non-WAC markup as well as control elements . APPENDIX A: Exemplary WAC.DTD

<!DOCTYPE eBAF-WAC-1.0 [

This DTD describes Web Authoring Controls, or WACs for short. A WAC is a productivety aid for authoring Web pages. A WAC can be used to simplifying the task of generating complex markup, or it can automate tedious tasks such as updating markup when the resources it depends on change. WACs execute at development time. All WAC tags can be stripped from the document when it is deployed to its runtime environment.

A WAC is contained in a document which may be HTML, JSP, or generic XML. The document is part of a project that contains related documents and resources. For example, a WAC could be used to generate navigation bars from a site map resource. The project and the document are part of the execution context of the WAC. In the course of execution, a WAC may read resources, update or delete existing resources, and create new resources . The tagging scheme used to imbed WACs in documents is XML compliant. All non-markup data (i.e. metadata) contained by WAC tags is represented as element attributes so that documents containing WACs can be displayed by ordinary Web browsers. In contrast, WebBots and DTCs store metadata in HTML comments which cannot be nested. The use of XML elements is more powerful since it allows WACs to be nested and thereby composed. For example, a page layout WAC could contain nested navigation WACs.

<!-- The <control> Element

A control is a JavaBean that generates markup from parameters. A control is like a parameterised macro. The parameters may be simple pieces of data, such as numbers or strings, or references to either other controls within the same document or resources located in the project.

A control simplifies Web authoring by presenting a user interface that assists the user in setting the parameters. The user interface is defined by the JavaBean and can be either a property sheet, with optional custom property editors, or a customiser. An editor should present a property sheet or customiser to the user when the control is selected for editing. A control can be used to automate tedious tasks, such as adding line numbers to listings, or to eliminate the need for the user to be able write complex HTML and JSP tags, or Java scriptlets.

A <control> element has the following attributes: name: a unique ID for the control so it can be referenced by other controls class: the name of the Java class that implements the control enabled: true if the control should regenerate its markup

The id attribute is an ID so that the control can be referenced by other controls.

The class attribute is the fully qualified name of the class that implements the control. The way that a WAC processor locates the class is undefined.

The enabled attribute allows the user to disable the control if desired. For example, the user may wish to temporarily change the generated markup.

A <control> element contains a <parameters> element that the parameters that are used to set the JavaBean properties and a <markup> element that contains the generated markup .

<! ELEMENT control (parameters, markup) > <!ATTLIST control id ID #REQUIRED class CDATA #REQUIRED enabled (true I false) "true">

<!-- The <parameters> Element

A <parameters> element contains the parameters that are used to set the control properties. Since the control is a JavaBean, its properties may be either single values or indexed.

A <parameters> element may contains zero or more <param> or

<paramarray> elements . A <param> element defines a single-valued property. A <paramarray> element defines an indexed property.

<! ELEMENT parameters (param | paramarray) *>

< ! - - The <param> Element

A <param> element defines a control property. It contains the following attributes : name: the property name value: the property name valuetype: the property value type, which can be one of the following: data: the value is simple data such as a number or string ref : the value is a URL object: the value is the ID of another element in this document

A value of type ref is a URL. The URL may be absolute or relative. If the URL begins with a scheme, e.g. "http:", then it is absolute. Otherwise it is relative.

A relative URL refers to another resource in the project. If the URL begins with "/" then it is relative to the project root. Otherwise, the URL is relative to the document. A WAC-compliant site management tool should update this value if the referenced resource is moved or renamed, or if the document is moved.

A value of type object is the ID of another element in the document. A WAC- compliant editor should update this value if the ID of the referenced element is changed. -->

<! ELEMENT param EMPTY> < 1ATTLIST param name CDATA #REQUIRED value CDATA #REQUIRED valuetype (data | ref | object) "data">

<!-- The <paramarray> Element

A <paramarray element defines a control indexed property. It contains the following attributes: name: the property name valuetype: the property value type (see the <param> element) A <paramarray> element contains zero or more <paramvalue> elements, which define the values of the indexed property. -->

<! ELEMENT paramarray (paramvalue) *> <!ATTLIST paramarray name CDATA #REQUIRED valuetype (data | ref | object) "data">

<!-- The <paramvalue> Element A <paramvalue> element defines the value of an indexed property for a given index. The position of a <paramvalue> element in the <paramarray> element defines the index.

A <paramvalue> element has the following attribute: value: the property value

< ! ELEMENT paramvalue EMPTY> <!ATTLIST paramvalue value CDATA #REQUIRΞD>

<!-- The <markup> Element

A <markup> element contains the markup generated by the control . A <markup> element may contain any valid non-WAC markup, and may also contain, either directly or indirectly, <control> and <usermarkup> elements .

An editor should treat any markup that is not contained in a <usermarkup> element as write-protected since any changes made to it by the user will be replaced when the markup is regenerated. In order to preserve user markup it must be contained in a <usermarkup> element.

If the user needs to change the generated markup, there are two options .

First, the user can disable the control by setting its enabled attribute to false. A WAC-compliant editor should provide a way for the user to enable or disable all or selected controls .

Second, the user can strip the WAC tags surrounding the generated markup from the document. A WAC-compliant editor should provide a way for the user to strip all or selected controls . < ! ELEMENT markup ANY >

<!-- The <usermarkup> Element

A <usermarkup> element allows the user to insert markup in the markup generated by a WAC. When the WAC regenerates the markup, the contents of <usermarkup> elements are normally preserved.

A <usermarkup> element has the following attribute: name: the name of the element which identifies its purpose

Although the contents of <usermarkup> elements are normally preserved, their relative order may change when the WAC regenerates the markup. In addition, new <usermarkup> elements may get generated and existing ones may get deleted. The WAC generates <usermarkup> elements and the WAC processor merges in the existing content by matching the name attributes .

A <usermarkup> element may any non-WAC markup and also <control> elements .

<! ELEMENT usermarkup ANY > <!ATTLIST usermarkup name CDATA "">

]>

Claims

1. A method of automatically generating display formatting instructions for a plurality of documents on a server for displaying the plurality of documents on a client during a run-time interval, the server having a plurality of formatting controls and a file with a first set of formatting instructions containing a plurality of references, each reference indicating one of the plurality of formatting controls and one of the plurality of documents, said method comprising: (A) processing said file to locate each of the plurality of references to form a tree;

(B) executing one of the plurality of formatting controls according to one of the plurality of references to create a second set of formatting instructions based on said indicated document in said one of the plurality of references;

(C) incorporating said second set of formatting instructions into an output file; and

(D) repeating steps (B) and (C) for each of the plurality of references in said tree; wherein each of the plurality of formatting controls indicated in the plurality of references is executed before the run-time interval.

2. The method according to claim 1 wherein the plurality of formatting controls are executed according to their depth in said tree in a depth-first order.

3. The method according to any preceding claim wherein the first set of formatting instructions and said second set of formatting instructions are both in a markup language .

The method according to any preceding claim further including:

removing the plurality of references from the first set of formatting instructions after executing each of the plurality of references in said tree.

5. The method according to any preceding claim wherein formatting instructions are of an automatically generate or user generated type, said first set of formatting instructions having said automatically generated and user generated types denoted therein, and wherein step (C) includes: (I) designating automatically generated formatting instructions in said second set of formatting instructions as said automatically generated type;

(II) designating user generated formatting instructions in said second set of formatting instructions as said user generated type; and

(III) inserting automatically generated formatting instructions and user generated instructions into the file according to the type of formatting instruction and the first set of formatting instructions .

6. The method according to claim 5 wherein step (III) includes:

(a) determining if portions of the first set of formatting instructions correspond with portions of said second set of formatting instructions ;

(b) inserting all portions of said second set of formatting instructions having no correspondence with the first set of formatting instructions ;

(c) replacing the corresponding portions of the first set of formatting instructions with corresponding portions of said second set of formatting instructions if portions of said second set of formatting instructions corresponding with portions of the first set of formatting instructions are of the automatically generated type; and

(d) reformatting said corresponding portions of the first set of instructions according to a format of corresponding portions of said second set of formatting instructions if portions of said second set of formatting instructions corresponding with portions of the first set of formatting instructions are of the user generated type.

7. The method according to claim 6 wherein step (d) includes: (i) creating a correspondence between corresponding portions in the first set of formatting instructions of the user generated type and corresponding portions in said second set of instructions of the user generated type; and

(ii) corresponding an order of said corresponding user generated type first set of formatting instructions to an order of said corresponding user generated type second set of formatting instructions.

8. The method according to any preceding claim wherein the file is one of a plurality of files and further including:

(E) prior to step (A) detecting a change in one of said plurality of files; and

(F) repeating steps (A) to (D) for each of said plurality of files.

9. A server computer system which carries out the method of any preceding claim.

10. A computer program product, stored on a computer readable storage medium for, when executed on a computer system, instructing the computer system to carry out the method of any preceding method claim.