Abstract:
A method for tracking assertions in an application is provided. The method includes providing a specification for the application, identifying each assertion in each chapter of the specification, and generating a markup language document. The specification is divided into chapters, which define functional aspects of the application. The markup language document has an associated tagged entry for each of the identified assertions. Each tagged entry has an identifier tag which correlates the tagged entry to a specific chapter of the specification.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    1. Field of the Invention  
           [0002]    The present invention relates generally to software processing, and more particularly, to methods and systems for improving computer software testing process by enhancing the representation of computer software specifications.  
           [0003]    2. Description of the Related Art  
           [0004]    As the use of software in performing daily tasks is increasing rapidly, assessing software reliability through software testing has become an imperative stage in software development cycle. As is well known, software testing is used to find and eliminate defects (i.e., bugs) in software, which if undetected, can cause the software to operate improperly.  
           [0005]    Generally, computer software testing starts by the implementation group creating an implementation document using the computer software specification. The software testers then review the implementation document to verify the compatibility of the implementation document with the specification document.  
           [0006]    Usually, for ease of reference, specification documents are divided into, among others, chapters, sections, subsections, and assertions. Furthermore, typically, a test suite is implemented to test each specification. In creating the test suite to test a particular specification, the test group architect manually reviews the specification document so as to find all the assertions. As used herein, assertions are defined as boolean expressions designed to convey a necessary behavior of the software program and are typically included in the text. Among others, assertions are identified by implementation specific terminology such as “must,” “should,” “always,” “optional,” etc.  
           [0007]    Upon finding all the assertions, each assertion is mapped to an application framework, which are then initiated so as to execute each of the corresponding assertions. A test suite is then developed using all of the application frameworks. After the development of each test suite has concluded, each test application framework mapped to the corresponding assertion in the specification. As this tedious and time consuming task is done manually by the test developers, the mapping task is considered to be one of many drawbacks of the prior art testing process.  
           [0008]    The above-mentioned shortcoming becomes even more pronounced if the specification document is modified subsequent to the locating and marking of the assertions. For instance, any revision to the specification requires the test developers to review the revised specification so as to locate all assertions, again, in an attempt to determine whether there have been any modifications to any of the chapters, sections, subsections, or assertions. That is, the test developer must match each of the initial assertions in the original specification against the assertions in the revised specification so as to determine whether any of the initial assertions has been modified or deleted, and whether any new assertions have been added. Simply stated, each of the assertions in the revised specification should be mapped to the corresponding assertion in the initial specification, if any. As matching the assertions is very time consuming, it slows down the test process and significantly reduces the productivity of test developers, thus marking the second shortcoming of the prior art testing process. Additionally, the initial test suite should be modified to include the revised application frameworks to accommodate each of the assertion modifications, additions, or deletions.  
           [0009]    Yet another shortcoming of the prior art software testing process is its inability to display just the assertions as they correspond to a chapter, section, and subsection. Additionally, the software testing process of the prior art lacks the flexibility to display varied information as requested by the test developers and users. As a consequence, retrieving or displaying of data becomes very time consuming and complicated, requiring the test developers to develop individual tools to achieve each of these tasks.  
           [0010]    In view of the foregoing, there is a need for a flexible methodology and system for enhancing software testing process by improving the representation of software specifications.  
         SUMMARY OF THE INVENTION  
         [0011]    Broadly speaking, the present invention fills these needs by providing a flexible method and system for improving the software testing process through simplifying a software specification representation by creating a second document using a markup language tags. In one example, the second document is an assertion document configured to be an Extensible Markup Language (XML) representation of the specification document. In one embodiment, the assertion document includes almost all the chapters, sections, subsections, and assertions of the specification documents as tagged using XML. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, or a method. Several inventive embodiments of the present invention are described below.  
           [0012]    In one embodiment, a method for tracking assertions in an application is disclosed. The method includes providing a specification for the application, identifying each assertion in each chapter of the specification, and generating a markup language document. The specification is divided into chapters, which define functional aspects of the application. The markup language document has an associated tagged entry for each of the identified assertions. Each tagged entry has an identifier tag which correlates the tagged entry to a specific chapter of the specification.  
           [0013]    In another embodiment, a method for tracking assertions in an application is disclosed. The method includes providing a specification for the application, identifying each assertion in each chapter of the specification, generating markup language document, and displaying the markup language document. The specification is divided into chapters, which define functional aspects of the application. The markup language document has associated tagged entry for each of the identified assertions. Each tagged entry has an identifier tag, which correlates the tagged entry to a specific chapter of the specification. The associated tagged entry for each of the identified assertions facilitates retrieval of a requested assertion.  
           [0014]    In yet another embodiment, a computer program embodied on a computer readable medium for facilitating a retrieval of an assertion in an application is disclosed. The computer program includes a code segment that receives a request to locate a particular assertion. The computer program also includes a code segment that runs during an execution of the computer program. The code segment is configured to inspect a markup language document to find the particular assertion. The computer program also includes a code segment that provides a response to the request to locate the particular assertion.  
           [0015]    Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0016]    The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, and like reference numerals designate like structural elements.  
         [0017]    [0017]FIG. 1A is a simplified illustration of an exemplary software specification, in accordance with one embodiment of the present invention.  
         [0018]    [0018]FIG. 1B- 1  is a simplified diagram illustrating the creating of an assertion document by tagging the plurality of assertions in the text of a software specification, in accordance with another embodiment of the present invention.  
         [0019]    [0019]FIG. 1B- 2  depicts the XML representation of a plurality of assertions in a chapter of the specification document, in accordance with yet another embodiment of the present invention.  
         [0020]    [0020]FIG. 1B- 3  depicts the XML representation of a plurality of assertions in a chapter of the specification document, in accordance to yet another embodiment of the present invention.  
         [0021]    [0021]FIG. 1B- 4  depicts the XML representation of a plurality of assertions in a chapter of the specification document, in accordance to still another embodiment of the present invention.  
         [0022]    [0022]FIG. 1B- 5  depicts the XML representation of a plurality of assertions in a chapter of the specification document, in accordance with still another embodiment of the present invention.  
         [0023]    [0023]FIG. 2A- 1  is a simplified illustration of a first revised specification and the creating of an assertion document by tagging the plurality of assertions in the text of the first revised specification, in accordance to yet another embodiment of the present invention.  
         [0024]    [0024]FIG. 2A- 2  depicts the XML representation of a plurality of assertions in a chapter of the first revised specification, in accordance to yet another embodiment of the present invention.  
         [0025]    [0025]FIG. 2A- 3  depicts the XML representation of a plurality of assertions in a chapter of the first revised specification, in accordance to yet another embodiment of the present invention.  
         [0026]    [0026]FIG. 2A- 4  depicts the XML representation of a plurality of assertions in a chapter of the first revised specification, in accordance to yet another embodiment of the present invention.  
         [0027]    [0027]FIG. 2A- 5  depicts the XML representation of a plurality of assertions in a chapter of the first revised specification, in accordance to yet another embodiment of the present invention.  
         [0028]    [0028]FIG. 3 is a flow chart diagram of method operations performed to create an XML assertion document, in accordance with yet another embodiment of the present invention.  
         [0029]    [0029]FIG. 4 is a flow chart diagram of method operations performed to create an assertion document using a software specification document, in accordance with yet another embodiment of the present invention.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0030]    Inventions for simplifying software specification testing by enhancing representation of software specifications through implementing a second document tagged using a markup language and methods for implementing the same, are disclosed. In one example, the second document is an assertion document wherein each chapter, section, subsection, and assertion is tagged using the Extensible Markup Language (“XML”), allowing the test developers to easily locate, retrieve, and display specific information, as needed. In one example, Extensible Stylesheet Language (XSLT) Stylesheet is implemented to transform the assertion document into a Hyper Text Markup Language (HTML) document. It will be understood, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.  
         [0031]    [0031]FIG. 1A is a simplified illustration of an exemplary software specification  100 , in accordance with one embodiment of the present invention. The software specification  100  includes a plurality of chapters, chapter  1   102  through chapter  4   102 ′″. As shown, each of the chapters, chapter  1   102 , chapter  2   102 ′, chapter  3   102 ″, and chapter  4   102 ′″ respectively include sections  104 - 104 ′,  110 , and  104 ″- 104 ′″.  
         [0032]    Each of the chapters  102  through  102 ′″ contains text  106  through  106 ′″, which as shown, each includes a plurality of assertions. In one example, the assertions can easily be identified while in a different example, the assertions are identified upon a closer inspection of the text by an assertion writer. As used herein, the assertion writer is the person who transforms the specification document into an assertion document.  
         [0033]    In the embodiment of FIG. 1A, the text  106  includes a plurality of assertions, first assertion  108   a , second assertion  108   b , and third assertion  108   c . The text  106 ′ contained within section  1 . 1   104 ′ of the chapter  102 ′ includes a fourth assertion  108   d , a fifth assertion  108   e , and a sixth assertion  108   f . As shown, the fourth assertion  108   d  has a sub-assertion, which is the fifth assertion  108   e . Furthermore as shown, the sixth assertion  108   f  depends on the third assertion  108   c . The text  106 ″ includes a seventh assertion  108   g  while the text  106 ′″ includes an eight assertion  108   h . The seventh assertion  108   g  in turn depends on the third assertion  108   c.    
         [0034]    Creating an assertion document  100 ′ by tagging the plurality of assertions in the text of software specification  100  is shown in the simplified diagram shown in FIG. 1B- 1 , in accordance with one embodiment of the present invention. The assertion document  100 ′ includes a specification box  150  and a plurality of chapter boxes  152  through  158 , each corresponding to one of the chapters  102  through  104 , respectively. The specification box  150  is designed to include information about the specification document  100  while assertion boxes  152  through  158  are configured to include information about all assertions included in the corresponding chapters  102  through  102 ′″.  
         [0035]    In one embodiment, an assertion document type definition (“DTD”) is configured to provide an XML DTD for defining the assertion document. The XML DTD is designed to provide the test developers or the users the format of the assertion document. In one example, comments in the XML DTD provide additional requirements for the syntax and semantics of XML elements in the assertion document. Several exemplary XML elements are provided below:  
         [0036]    Element spec: In one example, the spec element is configured to be the root of assertion.dtd. In one embodiment, the spec element defines the elements needed for expressing the specification document using the XML format. In one instance, the spec element requires the identification, name, version, define, and chapter+elements to describe the specification document. As designed, the name is configured to be the same as the name of specification document.  
         [0037]    ID Element: In one example, the id element is configured to describe a unique characteristic of the element.  
         [0038]    Name element: In one instance, the name element describes the name of the specification element. As designed, the name is configured to be unique when the name is used across more than one &lt;define&gt; element.  
         [0039]    Version Element: According to one embodiment, the version element is configured to describe the version of the specification document.  
         [0040]    Define Element: In one embodiment, the define element can be implemented to combine multiple assertion elements in a single assertion element. For instance, when an assertion covers more that one technology, the assertion writer may use the define element to refer to all the technologies. In one instance, a tool can be implemented to expand the assertion for each technology using the sub-assertion element. In one implementation, an assertion can use the define element by describing a &lt;name-link&gt; element in the value of the &lt;name&gt; element: For example, Table 1 includes an exemplary XML representation.  
                                                                                                                 TABLE 1                       Exemplary XML Representation                                &lt;assertion&gt;                 &lt;id&gt;EJB:2.0_PFD2:1:2:2 &lt;/id&gt;            &lt;name&gt; /ejb/&lt;name-link&gt; Enterprise Beans            &lt;/name-link&gt;/ejbCreate           &lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;           ...            &lt;/assertion&gt;       &lt;assertion&gt;                 &lt;id&gt; EJB:2.0_PFD2:1:2:2 &lt;/id&gt;            &lt;name&gt; /ejb/&lt;name-link&gt; Enterprise Beans            &lt;/name-link&gt;/ejbCreate           &lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;           ..           &lt;sub-assertions&gt;                &lt;sub-assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1.2.2#1 &lt;/id&gt;           &lt;name&gt; /ejb/Statefull Session Bean/ejbCreate &lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;                &lt;/sub-assertion&gt;           &lt;sub-assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1.2.2#2 &lt;/id&gt;           &lt;name&gt;/ejb/BeanManagedPersistence/ejbCreate           &lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;                &lt;/sub-assertion&gt;                &lt;/sub-assertions&gt;            &lt;/assertions&gt;                  
 
         [0041]    In this manner, once the &lt;name-link&gt; element is expanded, the define element can be removed from the assertion document.  
         [0042]    Union Element: In one instance, the union element describes almost all the &lt;name&gt; elements used to describe the name of a higher level assertion.  
         [0043]    Element Element: According to one embodiment, the element element defines the name of a sub-assertion.  
         [0044]    Name-link Element: In one example, the name-link element is used in conjunction with the &lt;define&gt; element. In one instance, the name-link element can be configured to refer to a define name element.  
         [0045]    Chapter Element: According to one embodiment, the chapter element is configured to contain almost all the information implemented to describe a specification document using XML. In one example, the name element is configured to be almost identical to the name of the associated specification. The description is configured to be a short sentence describing an overview of the chapter. In one example, a chapter can also define some assertions. However, in one instance, the assertions are configured to be defined at the section level.  
         [0046]    Description Element: In one example, the description element contains a full description of the element. If the description element is used with the assertion element, the description element is configured to contain information describing the assertion in more detail. To the extent possible, the description is designed to be taken from the specification.  
         [0047]    Section Element: In one example, the section element is configured to contain almost all the information required to describe a specification section. The name element is configured to be substantially the same as the specification section name. The description is designed to be a short sentence providing an overview of the section.  
         [0048]    Assertions Element: In one instance, the assertions element is configured to describe almost all the elements required to be implemented to express a specification assertion using XML.  
         [0049]    Assertion Element: In one instance, the assertion element is the XML view of a specification assertion. By way of example, the identification and the name elements are configured to be unique while the description is designed to be taken integrally from the specification document. In one embodiment, keywords can be used to describe an assertion and the spec-refs element can be used to refer to a different ID element. In one embodiment, if the assertion name includes a &lt;define&gt; element, the sub-assertion can be expanded by a tool or by the assertion writer.  
         [0050]    An assertion can further include attributes to describe the state of the assertion. In one example, the following attributes are included:  
         [0051]    type: In one embodiment, the type attribute defines the assertion type, which in one example, can be one of positive, negative, untestable or deprecated.  
         [0052]    predef: In accordance with one embodiment, the predef element is an assertion that was defined earlier in the document, which in one example, is used in a different context. Some specification documents are configured to repeat the assertion at the beginning of a section, chapter, etc.  
         [0053]    optional: In one example, an assertion can be optional. In one instance, an assertion attribute can be assigned to be either true or false. In one embodiment, when the specification includes certain recommendations regarding the assertion, the default attribute of an assertion is assigned to be false. Otherwise, in a different aspect, the assertion attribute is assigned to be true.  
         [0054]    implementation_specific: In one example, an assertion can be product specific. In one example, the specification recommends a behavior of the assertion.  
         [0055]    category: In one example, the category attribute is the characteristic of the assertion. For instance, the assertion can be classified under:  
         [0056]    spec: In one embodiment, a specification assertion is an assertion that the entire product must realize. In one example, the specification assertion is configured to implement a specification feature uniformly throughout the specification. Usually, the description of the assertion contains words such as: “must,” “may,” “should,” etc. In one example, optional or implementation specific assertions can also be marked as spec assertions.  
         [0057]    usage: In one instance, the usage attribute is used when an assertion contains a sub-assertion using the &lt;depend&gt; element. In one example, the usage assertion is designed to address a more complex scenario than a spec assertion.  
         [0058]    Algorithm: In one instance, the algorithm is an assertion that represents an algorithm.  
         [0059]    According to one example, an assertion writer takes the following items in consideration:  
         [0060]    In one instance, when possible, the assertion description is configured to be taken from the specification without changing the wording.  
         [0061]    In one embodiment, a usage assertion is composed of more than one specification assertion.  
         [0062]    For instance, a high level assertion uses the predef element to refer to the assertion it is describing.  
         [0063]    In one example, if an assertion description contains must, should, may, etc., the assertion is an spec assertion.  
         [0064]    In accordance to one implementation, substantially all assertions should be represented within the assertion document even if the assertion is difficult to test.  
         [0065]    By way of example, the keyword element is configured to be used as many time as possible. In one embodiment, an assertion can have more than one keyword associated with it.  
         [0066]    In one instance, in an attempt to avoid duplication, the assertion writer is configured to confirm that the assertion was not previously defined in the document.  
         [0067]    Keywords Element: In accordance with one embodiment, the keywords element is configured to define a set of keywords associated with an assertion. In one instance, a tool or XSLT Stylesheet can be used to extract assertions based on the keywords.  
         [0068]    Keyword Element: In one embodiment, the keyword element is designed to describe a keyword associated with an assertion. According to one embodiment, a tool or XSLT Stylesheet can be used to extract assertions based on their respective keywords.  
         [0069]    Spec-refs Element: In one example, the spec-refs element is configured to describe a secondary ID for the assertion. For instance, an assertion can have a plurality of identifications referenced in the &lt;spec-ref&gt; element. In one embodiment, the &lt;id&gt; element can be referenced using the &lt;spec-ref&gt; element. An exemplary spec-refs is provided below in Table 2.  
                                     TABLE 2                       Exemplary XML Representation Using XML                                &lt;id&gt; J2EE:1.3:1:1.1 &lt;/id&gt;       &lt;spec-refs&gt;                &lt;spec-ref&gt; j2ee:1.2:1:1.2 &lt;/spec-ref&gt;            &lt;spec-refs&gt;                  
 
         [0070]    Spec-ref Element: In one example, the spec-ref element is configured to describe a different &lt;id&gt; implemented to reference an assertion. In one embodiment, the identifications can be used when the specification is revised.  
         [0071]    In one embodiment, the assertion document may not contain any links to the XSLT Stylesheet file. In such a scenario, a tool capable of transforming the XML assertion document into another document having a different format (ex: html) is configured to be used.  
         [0072]    In accordance to one embodiment, an exemplary XML DTD is provided in Table 3.  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         TABLE 3                       Exemplary XML DTD for an Assertion Document                                &lt;!--       This is an example of the XML DTD for assertion documents.       --&gt;                &lt;?xml version=“1.0” encoding=“UTF-8”?&gt;           &lt;!DOCTYPE spec SYSTEM            ‘http://sardinia.sfbay:8080/ejte/assertion/dtds/assertions.dtd’&gt;       &lt;!--       In accordance with one example, the spec element is the root of assertion.dtd. It       defines the elements needed for expressing the specification document using XML       format. The name is the same as the specification document.       --&gt;       &lt;!ELEMENT spec (id, name, version, define*, chapter+)&gt;       &lt;!--       The id element describes the unique id of an element.       Used in: spec, chapter, section, assertion, sub-assertion, and define       --&gt;       &lt;!ELEMENT id (#PCDATA)&gt;       &lt;!--       In one example, the name element describes the name of the specification element.       The name is configured to be unique when it is used across more than one &lt;define&gt;       element.       Used in: spec, chapter, section, assertion, sub-assertion, and define       --&gt;       &lt;!ELEMENT name (#PCDATA | name-link)*&gt;       &lt;!--       By way of example, the version element describes the version of the specification       document.       Used in: spec       --&gt;       &lt;!ELEMENT version (#PCDATA)&gt;       &lt;!--       In accordance with one embodiment, the define element is used to combine multiple       assertion &lt;name&gt; element in a single assertion. When an assertion covers more that       one technology, the assertion writer may use the define element to reference all the       technologies. Later, a tool can expand each technology assertion using the sub-       assertion element. For instance:                &lt;define&gt;                 &lt;id&gt; EJB:1 &lt;/id&gt;           &lt;name&gt; Enterprise Beans &lt;/name&gt;           &lt;union&gt;                &lt;element&gt; Stateless Session Bean &lt;/element&gt;           &lt;element&gt; Stateful Session Bean &lt;/element&gt;           &lt;element&gt; Bean Managed Persistence &lt;/element&gt;           &lt;element&gt; Container Managed Persistence &lt;/element&gt;           &lt;element&gt; Message-Driven Bean &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;            In accordance with one embodiment, an assertion can use the define element by       defining a &lt;name-link&gt; element in the &lt;name&gt; value:                &lt;assertion&gt;                 &lt;id&gt;EJB:2.0_PFD2:1:2:2 &lt;/id&gt;            &lt;name&gt;   /ejb/&lt;name-link&gt;   Enterprise  Beans  &lt;/name-           link&gt;/ejbCreate&lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;           ....                &lt;/assertion&gt;            Thereafter, a tool can be used to expand the &lt;define&gt; element:                &lt;assertion&gt;                 &lt;id&gt; EJB:2.0_PFD2:1:2:2 &lt;/id&gt;            &lt;name&gt; /ejb/&lt;name-link&gt; Enterprise Beans &lt;/name- link&gt;/ejbCreate           &lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;           ...           &lt;sub-assertions&gt;                &lt;sub-assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1.2.2#1 &lt;/id&gt;           &lt;name&gt; /ejb/Statefull Session Bean/ejbCreate &lt;/name&gt;           &lt;description&gt; .... &lt;/description&gt;                &lt;/sub-assertion&gt;           &lt;sub-assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1.2.2#2 &lt;/id&gt;           &lt;name&gt;/ejb/BeanManaged           Persistence/ejbCreate&lt;/name&gt;           &lt;description&gt; .... &lt;/description&gt;                &lt;/sub-assertion&gt;                &lt;/sub-assertions&gt;                &lt;/assertions&gt;            It must be noted that in one example, although not required, once the &lt;name-link&gt;       element has been expanded, the define element can be removed from the document.       Used in: name       --&gt;       &lt;!ELEMENT define (id, name, description, union)&gt;       &lt;!--       In one example, the union element describes the &lt;name&gt; elements used to describe a       higher level assertion name.       Used in: define       --&gt;       &lt;!ELEMENT union (element+)&gt;       &lt;!--       In accordance to one embodiment, the element defines the name of a sub-assertion.       Used in: union       --&gt;       &lt;!ELEMENT element (#PCDATA)&gt;       &lt;!--       According to one embodiment, the name-link element is used in conjunction with a       &lt;define&gt; element. The name-link element references a define name element.       Used in: name       --&gt;       &lt;!ELEMENT name-link (#PCDATA)&gt;       &lt;!--       In one example, the chapter element contains almost all the required information used       to describe a chapter in the specification document using XML. The name element is       the associated specification chapter name. The description is configured to be a short       sentence describing an overview of the chapter. In one embodiment, although       assertions are defined at the section level, a chapter can also define some assertions.       Used in: spec       --&gt;       &lt;!ELEMENT chapter ( id, name, description, assertions?, section*, spec-refs? )&gt;       &lt;!--       In accordance to one embodiment, the description element contains a full description       of the element. In one example, when used with the assertion element, the description       contains information describing the assertion in detail. If possible, the description is       taken integrally from the specification.       Used in: spec, chapter, section, define, assertion, and sub-assertion.       --&gt;       &lt;!ELEMENT description (#PCDATA)&gt;       &lt;!--       In one instance, the section element contains the required information to describe a       specification section using XML. The name element is configured be the name of       specification section. The description can be a short sentence providing an overview       of the section.       Used in: chapter       --&gt;       &lt;!ELEMENT section ( id, name, description, assertions?, spec-refs? )&gt;       &lt;!--       In one example, the assertions element describes the required elements used for       expressing a specification assertion using XML.       Used in: chapter and section.       --&gt;       &lt;!ELEMENT assertions ( depends*, assertion* )&gt;       &lt;!--       In one example, the assertion element is an XML view of a specification assertion.       The id and the name elements are configured to be unique while the description is       designed to be taken integrally from the specification. Keywords can be used to       describe an assertion. &lt;spec-refs&gt; can be used to refer to a different ID element. In       accordance with one implementation, if the assertion name uses a &lt;define&gt; element,       sub-assertion can be expanded by a tool or the assertion writer. An assertion may also       have the following attributes used for describing the state of the assertion:                type: In one instance, the type attribute defines the assertion type (e.g.,           positive, negative, untestable, deprecated, etc.)           predef: By way of example, an assertion can be defined earlier in the           document and be used in a different context later on in the document. In           accordance to one embodiment, the specification document repeats the           assertion at the beginning of a section, a chapter, etc.           optional: In one instance, an assertion can be optional (e.g., true or false).           implementation_specific: According to one embodiment, an assertion can be           product specific.           Category: In one instance, the category is the category under which the           assertion can be classified. By way of example, the assertion can be classified           under:                Spec: In one instance, a specification assertion is an assertion that           products realize. Usually, the assertion description contains words           such as “MUST,” “MAY,” “SHOULD,” etc. According to one           example, optional or implementation specific assertions can also be           marked as a spec assertion.           Usage: In one embodiment, the usage assertion is an assertion that           contains a sub-assertion which uses the &lt;depend&gt; element. By way           of example, the usage assertion can consist of a more complex           scenario than a spec assertion.           Algorithm: In one embodiment, the algorithm assertion is an           assertion that represents an algorithm.            Used in: assertions       --&gt;       &lt;!ELEMENT assertion (id, name, description, depends*, spec-refs?, sub-assertions*,       keywords* )&gt;       &lt;!ATTLIST assertion                type ( positive | negative | deprecated | untestable) “positive”           predef CDATA #IMPLIED           optional (true | false) “false”           implementation_specific (true | false) “false”           category (spec | usage | algorithm ) #IMPLIED&gt;            &lt;!--       In one instance, the keywords element defines a set of keywords associated with an       assertion. A tool or XSLT Stylesheet can be used to extract assertions based on the       keywords.       Used in: assertion       --&gt;       &lt;!ELEMENT keywords (keyword+)&gt;       &lt;!--       In one instance, the keyword element describes a keyword associated with the       assertion. A tool or XSLT Stylesheet can be used to extract assertions based on their       respective keywords.       Used in: keyword       --&gt;       &lt;!ELEMENT keyword (#PCDATA)&gt;       &lt;!--       In one example, the depends element contains all the dependencies of an assertion, a       section, a chapter, etc. The depend element is used to describe a scenario in which a       second assertion can be realized after a first assertion has been realized.                &lt;assertion&gt;                 &lt;id&gt; EJB:2.0_PFD2:1:2:2 &lt;/id&gt;            &lt;name&gt; /ejb/&lt;name-link&gt; Enterprise Beans &lt;/name-link&gt;/ejbCreate           &lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;           .&lt;depends&gt;                &lt;depend&gt; EJB:2.0_PFD2:1:1:1 &lt;/depend&gt;                &lt;/depends&gt;                &lt;/assertion&gt;            Used in: chapter, section, and assertion.       --&gt;       &lt;!ELEMENT depends (depend+)&gt;       &lt;!--       By way of example, the depends order attribute is used when the execution of one       assertion follows the execution of multiple assertions. Ex:                Assertion 3 must always occur after assertion 1 and assertion 6                &lt;depends order=“assertion 1, assertion 6”&gt;                &lt;depend&gt; assertion 1 &lt;/depend&gt;           &lt;depend&gt; assertion 6 &lt;/depend&gt;                &lt;/depends&gt;            Used in: depend       --&gt;       &lt;!ATTLIST depends                order CDATA #IMPLIED&gt;            &lt;!--       In one example, the depend element describes the dependency of an assertion on       another assertion. In one instance, the element value is an assertion &lt;id&gt; value.       Used in: depends       --&gt;       &lt;!ELEMENT depend (#PCDATA)&gt;       &lt;!--       In one example, the spec-refs element describes a secondary ID for the assertion. An       assertion can have multiple id(s) referenced in the &lt;spec-ref&gt; element.                &lt;id&gt; J2EE:1.3:1:1.1 &lt;/id&gt;           &lt;spec-refs&gt;                &lt;spec-ref&gt; j2ee:1.2:1:1.2 &lt;/spec-ref&gt;                &lt;spec-refs&gt;            In one embodiment, the &lt;id&gt; element can be referenced using the &lt;spec-ref&gt; element.       Used in: assertion       --&gt;       &lt;!ELEMENT spec-refs (spec-ref+)&gt;       &lt;!--       According to one implementation, the spec-ref element describes a different &lt;id&gt; used       for referencing an assertion. These IDs can be used when the specification changes.       Used in: spec-refs       --&gt;       &lt;!ELEMENT spec-ref (#PCDATA)&gt;       &lt;!--       In one instance, the sub-assertions element is used to expand an assertion name that       contains a &lt;name-link&gt; element to a &lt;define&gt; element. The spec-ref element can be       defined manually (i.e., meaning without using a tool, the define element, or the name-       link element).       Used in: assertion       --&gt;       &lt;!ELEMENT sub-assertions (sub-assertion+)&gt;       &lt;!--       In one example, the sub-assertion element expands an assertion based on the &lt;define&gt;       element. The ID of a sub-assertion follows the following rule:                &lt;assertion parent is&gt; + # + unique id            Ex:                &lt;assertion&gt;                 &lt;id&gt; EJB:2.0_PFD2:1:2:2 &lt;/id&gt;            &lt;name&gt; /ejb/&lt;name-link&gt; Enterprise Beans &lt;/name-           link&gt;/ejbCreate&lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;           ..           &lt;sub-assertions&gt;                &lt;sub-assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1.2.2#1 &lt;/id&gt;           &lt;name&gt; /ejb/Statefull Session Bean/ejbCreate &lt;/name&gt;           &lt;description&gt; .... &lt;/description&gt;                &lt;/sub-assertion&gt;           &lt;sub-assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1.2.2#2 &lt;/id&gt;           &lt;name&gt;/ejb/BeanManaged           Persistence/ejbCreate&lt;/name&gt;           &lt;description&gt; .... &lt;/description&gt;                &lt;/sub-assertion&gt;                &lt;/sub-assertions&gt;                &lt;/assertions&gt;            --&gt;       &lt;!--       In one example, the sub-assertion element is an XML view of a specification assertion.       According to one embodiment, the id and the name element are unique and the       description is taken integrally from the assertion that the sub-assertion is realized. In       one instance, a sub-assertion has attributes used for describing the state of the       assertion:                type: In one example, the type element defines the sub-assertion type (e.g.,           positive, negative, untestable, deprecated, etc.)           predef: In one embodiment, a sub-assertion can be defined earlier in the           document and be used in a different context later on in the document. By way           of example, some specification documents repeat the sub-assertion at the           beginning of a section, chapter, etc.           optional: In one example, a sub-assertion can be optional (e.g., true or false).           implementation_specific: In accordance to one embodiment, a sub-assertion           can be product specific.           Category: By way of example, the category under which the assertion can be           categorized. According to one implementation, the sub-assertion can be           classified under:                spec: In one example, a specification sub-assertion is an assertion           that products realize. Usually, the sub-assertion description           contains words like “MUST,” “MAY,” “SHOULD,” etc. Optional           or implementation specific assertions can also be marked as spec           assertions.           usage: In accordance to one embodiment, the usage assertion is an           assertion that contains a sub-assertion which uses the &lt;depend&gt;           element. The usage assertion can consist of a more complex           scenario than a spec assertion.           Algorithm: A sub-assertion that represents an algorithm.            Used in: assertion       &lt;!ELEMENT sub-assertion (id, name, description?)&gt;       &lt;!ATTLIST sub-assertion                type ( positive | negative | deprecated | untestable) “positive”           predef CDATA #IMPLIED           optional (true | false) “false”           implementation_specific (true | false) “false”                      
 
         [0073]    With a continued reference to FIG. 1B- 1 , in one example, the assertion writer is configured to include the following information about the specification document  100  in the specification box  150 :  
         [0074]    Specification name: In one example, the assertion writer is configured to assign a logical name to each specification document;  
         [0075]    Specification id: In one embodiment, the assertion writer is configured to assign an ID to each specification document. The ID is designed to be unique across an assertion document. An exemplary ID is:  
         [0076]    ejb (for Enterprise Java bean)  
         [0077]    Specification version: In one instance, the assertion writer is configured to assign a unique specification version for each assertion document. In one example it is the specification version.  
         [0078]    Table 4 includes the contents of the specification box  150 .  
                                     TABLE 4                       Exemplary XML Representation in a Specification Box                                &lt;spec&gt;                &lt;id&gt; Java Server Pages &lt;id&gt;           &lt;name&gt; Java Server Pages &lt;/name&gt;           &lt;version&gt; 1.2_PDF1 &lt;/version&gt;           &lt;description&gt; The JSP is compiled into a servlet &lt;/description&gt;            &lt;/spec&gt;                  
 
         [0079]    The contents of exemplary assertion boxes  152  through  158  are discussed in more detail below with respect to FIGS.  1 B- 2  through  1 B- 5 .  
         [0080]    [0080]FIG. 1B- 2  depicts the contents of an assertion box  152 , in accordance with one embodiment of the present invention. In one example, an assertion box is configured to include the following information:  
         [0081]    Chapter name: In one example, the assertion writer is configured to re-use the specification chapter name when creating the assertion document. The chapter name is configured to be the same for both, the specification document and the assertion document.  
         [0082]    Chapter id: In one instance, the assertion writer is configured to re-use the specification chapter number when creating the assertion document. The chapter id is designed to be the same for both specification and assertion document. The chapter id is designed to be unique.  
         [0083]    Section name and sub-section name: In one implementation, the assertion writer is configured to re-use the specification section name or sub-section name when creating the assertion document. By way of example, the section name (or sub-section name) is designed be the same for both the specification and the assertion document.  
         [0084]    Section id and sub-section id: In one embodiment, the assertion writer is configured to re-use the specification section number when creating the assertion document. The section id is designed to be the same for both the specification and assertion documents. Again, the section id is designed to be unique. In one instance, the uniqueness of the section id and subsection id is configured to be across the same section and same subsection elements within one particular chapter element.  
         [0085]    Assertion name and sub-assertion name: In one example, the assertion writer is configured to assign a name to each of the assertions. The name is designed to be based on the descriptors such as: specification, technology, operation to achieve, etc. In one instance, each descriptor is configured to be separated using the “/” character. An example is:  
         [0086]    /ejb/entity bean/container managed persistence/ejbLoad  
         [0087]    Assertion id and sub-assertion id: By way of example, the assertion writer is configured to assign a unique id to an assertion. The id is designed to be based on the specification id, the specification chapter, and the specification section where the assertion is defined.  
         [0088]    Assertion keyword and sub-assertion keyword: In one example, the assertion writer may assign one or more keywords to an assertion. The keyword is configured to be based on certain criteria such as a behavior of the specification, the technology, etc.  
         [0089]    Chapter, section and assertion ID definition: In one instance, the rule depicted in Table 5 is followed to define an element ID. In one example, this rule may not be applied to define a sub-assertion ID:  
                         TABLE 5                       Exemplary Assertion Rule                                    Specification ID:           Specification version + “_” + Specification release version:           Chapter number:           Section or sub-section number:           Unique ID:                      
 
         [0090]    An exemplary element ID is:  
         [0091]    EJB:2.0_PFD2:1:1:1  
         [0092]    Sub-assertion ID definition: In one instance, the rule in Table 6 is configured to be followed when defining a sub-assertion ID:  
                         TABLE 6                       Exemplary Assertion Rule                                    Specification ID:           Specification version + “_” + Specification release version:           Chapter number:           section number:           assertion unique ID + “#” + unique ID for sub-assertion                      
 
         [0093]    In one example, it is recommended to assign a unique ID number starting from 0, 1, 2 . . . . An exemplary sub-assertion is:  
         [0094]    EJB:2.0_PFD2:1:1:1#5  
         [0095]    Referring back to FIG. 1B- 2 , representing the first, second, and third assertions  108   a  through  108   c  using the XML tags can further be understood, in accordance with one embodiment. In one example, the XML representation of the first assertion  108   a  is shown in Table 7.  
                                               TABLE 7                       Exemplary First Assertion XML Tags                                &lt;assertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF1:1:1.1:1 &lt;/id&gt;           &lt;name&gt; /JSP/dynamic-content/HTML &lt;/name&gt;           &lt;description&gt; Java Server Pages in the           technology to generate dynamic                content in HTML &lt;/description&gt;            &lt;/assertion&gt;                  
 
         [0096]    In a like manner, Table 8 contains the exemplary XML tag codes for the second assertion  108   b  and the third assertion  108   c .  
                                                                         TABLE 8                       Exemplary XML Representation                                &lt;/assertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF1:1:1.1:2 &lt;/id&gt;           &lt;name&gt; JSP/dynamic-content/XHTML &lt;/name&gt;           &lt;description&gt; Java Server Pages in the           technology to generate dynamic                content in XHTML &lt;/description&gt;            &lt;/assertion&gt;       &lt;/assertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF1:1:1.1:3 &lt;/id&gt;           &lt;name&gt; JSP/dynamic-content/XML &lt;/name&gt;           &lt;description&gt; Java Server Pages is the           technology to generate dynamic                content in XML &lt;/description&gt;            &lt;/assertion&gt;                  
 
         [0097]    Referring now to FIG. 1B- 3 , XML representation of the assertions contained within the chapter  104 ′ can be further be understood, in accordance to one embodiment of the present invention. As illustrated, the fifth assertion  108   e  is the sub-assertion of the fourth assertion  108   d . As used herein, the sub-assertion element is configured to expand an assertion using the &lt;define&gt; element. In one instance, the sub-assertion element is an XML view of an assertion in the specification document. In one example, the id and the name element of the sub-assertion is configured to be unique. Furthermore, in one instance, the description of the sub-assertion is taken integrally from the assertion the sub-assertion depends on.  
         [0098]    In one embodiment, a sub-assertion ID may be designed to follow the rule in Table 9:  
                         TABLE 9                       Exemplary Sub-assertion Rule                                    &lt;assertion parent id&gt; + # + unique id                      
 
         [0099]    By way of example, the XML representation of the fourth assertion  108   d  and the sub-assertion  108   e  is shown in Table 10.  
                                                                                       TABLE 10                       Exemplary XML Sub-assertion Representation                                &lt;assertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF1:2:2.1:1 &lt;/id&gt;           &lt;name&gt; /JSP/protocol/HTTP &lt;/name&gt;           &lt;description&gt; HTTP is the default protocol for requests and responses           &lt;/description&gt;                &lt;subassertions&gt;                &lt;subassertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF1:2:2.1:# &lt;/id&gt;           &lt;name&gt; JSP/Requests/JSP/Protocol/HTTP &lt;/name&gt;           &lt;description&gt;  HTTP is           the default protocol for requests           &lt;/description&gt;                &lt;/subassertion&gt;                &lt;/subassertions&gt;            &lt;/assertion&gt;                  
 
         [0100]    In one implementation, the sub-assertion can be designed to have attributes to describe the state of the assertion. In one example, the sub-assertion has the following exemplary attributes:  
         [0101]    type: In one example, the type attribute defines the sub-assertion type, which may be positive, negative, untestable, or deprecated.  
         [0102]    predef: In one instance, a sub-assertion can be earlier defined in the document (i.e., duplicate) can be used in a different context. By way of example, some specification documents are designed to repeat the sub-assertion at the beginning of each section, chapter, etc.  
         [0103]    optional: In one implementation, a sub-assertion can be designed to be optional. That is, the sub-assertion can be assigned a value of either true or false.  
         [0104]    implementation_specific: By way of example, the sub-assertion can be configured to be product specific.  
         [0105]    category: In one instance, the sub-assertion can be classified under the same category as the assertion. By way of example, the subassertion can be classified as:  
         [0106]    spec: In one embodiment, a specification sub-assertion is an assertion that substantially all products must realize. In one instance, the sub-assertion description can be configured to contain words such as “MUST,” “MAY,” “SHOULD,” etc. In one implementation, optional or implementation specific implementation can also be marked as spec assertion;  
         [0107]    usage: In one instance, an assertion containing a sub-assertion implements the &lt;depend&gt; element. According to one embodiment, the &lt;depend&gt; element is configured to be a more complex scenario than a spec assertion; and  
         [0108]    algorithm: In one embodiment, algorithm assertion is a sub-assertion configured to represent an algorithm.  
         [0109]    An exemplary multi sub-assertion XML representation is shown in Table 11.  
                                                                                                               TABLE 11                       Exemplary Multi-sub-assertion XML Representation                                    &lt;assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1:2:2 &lt;/id&gt;           &lt;name&gt;  /ejb/&lt;name-link&gt;           Enterprise  Beans  &lt;/name-           link&gt;/ejbCreate&lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;           ..           &lt;sub-assertions&gt;                &lt;sub-assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1.2.2#1 &lt;/id&gt;           &lt;name&gt; /ejb/Statefull Session Bean/ejbCreate &lt;/name&gt;           &lt;description&gt; .... &lt;/description&gt;                &lt;/sub-assertion&gt;           &lt;sub-assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1.2.2#2 &lt;/id&gt;           &lt;name&gt;/ejb/BeanManaged           Persistence/ejbCreate&lt;/name&gt;           &lt;description&gt; .... &lt;/description&gt;                &lt;/sub-assertion&gt;                &lt;/sub-assertions&gt;                &lt;/assertions&gt;            --&gt;                  
 
         [0110]    Furthermore, as discussed with respect to FIG. 1B- 1 , the sixth assertion  108   f  depends on the third assertion  108   c  requiring the execution of the third assertion  108   c  prior to the execution of the sixth assertion  108   f . In one example, the dependency of one assertion on a different assertion is shown implementing the &lt;depends&gt; element. By way of example, dependency of the sixth assertion  108   f  on the third assertion  108   c  is shown in Table 12.  
                                                                             TABLE 12                       Exemplary Assertion Dependency                                &lt;assertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF1:2:2.1:2 &lt;/id&gt;           &lt;name&gt; JSP/Protocol/HTTPS &lt;/name&gt;           &lt;description&gt; HTTP is the secure protocol for requests and responses                that JSP also supports &lt;/description&gt;                &lt;depends&gt;                &lt;depend&gt; Java Server Pages: 1.2_PDF1:2:1.1:3 &lt;/depend&gt;                &lt;depends&gt;            &lt;/assertion&gt;                  
 
         [0111]    In one instance, the depends element contains almost all the dependencies of an assertion, a section, or a chapter. By way of example, first assertion is required to be executed before a second assertion can be executed. As shown in Table 13, in one embodiment, the depend element is used to describe the dependency an assertion can have on another assertion. As designed, the element value is configured to be an assertion &lt;id&gt; value.  
                                                         TABLE 13                       Exemplary XML Representation Using the Depend Element                                &lt;assertion&gt;                &lt;id&gt; EJB:2.0_PFD2:1:2:2 &lt;/id&gt;           &lt;name&gt;   /ejb/&lt;name-link&gt;             Enterprise  Beans  &lt;/name-           link&gt;/ejbCreate&lt;/name&gt;           &lt;description&gt; ... &lt;/description&gt;           .&lt;depends&gt;                &lt;depend&gt; EJB:2.0_PFD2:1:1:1 &lt;/depend&gt;                &lt;/depends&gt;            &lt;/assertion&gt;                  
 
         [0112]    Referencing to FIG. 1B- 4 , an XML representation of a multi-assertion dependency is illustrated in more detail, in accordance with one embodiment of the present invention. As shown, the seventh assertion  108   g  can be executed after the sixth assertion  108   f  has been executed. In turn, the sixth assertion  108   f  can be executed after the third assertion  108   c  has been executed. Thus, the seventh assertion  108   g  is executed after the third assertion  108   c  and the sixth assertion  108   g  have been executed.  
         [0113]    The &lt;depends order&gt; attribute can be used to describe the scenario in which the execution of one assertion is designed to follow the execution of more than one assertions. An exemplary XML representation implementing &lt;depends order&gt; is shown in Table 14. In this scenario, an assertion “g” is configured to occur after assertion “a” and assertion “d.” 
                                     TABLE 14                       Exemplary XML Representation                                &lt;depends order=“assertion a, assertion d”&gt;                &lt;depend&gt; assertion b &lt;/depend&gt;           &lt;depend&gt; assertion c&lt;/depend&gt;            &lt;/depends&gt;                  
 
         [0114]    Thus, the XML representation of the seventh assertion is described below in Table 15.  
                                                                   TABLE 15                       Exemplary XML Representation of Assertion 7                                &lt;assertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF1:3:3.2:1 &lt;/id&gt;           &lt;name&gt; JSP/default-request-object/HTTP Servlet Request &lt;/name&gt;           &lt;description&gt; The default request object is expected to extend            HTTP Servlet Request &lt;/description&gt;           &lt;depends order = “Java Server Pages: 1.2_PDF1:1:1.1:3,                Java Server Pages: 1.2_PDF1:2:2.1:3”&gt;                &lt;depend&gt; Java Server Pages: 1.2_PDF1:1:1.1:3 &lt;/depend&gt;           &lt;depend&gt; Java Server Pages: 1.2_PDF1:2:2.1:3 &lt;/depend&gt;                &lt;/depends&gt;            &lt;/assertion&gt;                  
 
         [0115]    The XML representation of the eighth assertion  108  is shown in FIG. 1B- 5 , in accordance with one embodiment of the present invention. As also shown in Table 16, the eight assertion is located in section  1 . 2  of chapter  4 .  
                                     TABLE 16                       XML Representation of Assertion 8                                &lt;/assertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF1:4:4.1:1 &lt;/id&gt;           &lt;name&gt; JSP/default-response-object/HHpServlet Response &lt;/name&gt;           &lt;description&gt; The default request object is           expected to extend HHpServlet            Response &lt;/description&gt;            &lt;/assertion&gt;                  
 
         [0116]    [0116]FIG. 2A- 1  illustrates a first revised specification  200  of the specification  100 , in accordance with one embodiment of the present invention. As shown, while the first revised specification  200  still includes chapters  102  through  102 ′″, certain modifications have been made to the assertions and sections. By way of example, the third assertion  108   c  of the specification  100  has been deleted in the first revised version  200 , while the assertions  108   a  and  108   b  of section  1 . 1   104  have remained unchanged. Section  2 . 1   104 ′ of chapter  102 ′ only includes the fourth assertion  108   d  and the fifth assertion  108   e . Since the third assertion  108   c  has been deleted in the specification  200 , all depending assertions (i.e., the sixth assertion  108   f  and the seventh assertion  108   g ) have also been deleted. Thus, as shown, the sixth assertion  108   f  has been deleted in the first revised specification  200 .  
         [0117]    Section  3 . 2   110  of chapter  3   102 ″ has been modified since the seventh assertion  108   g  has been deleted in the first revised specification  200 . In addition to deleting the seventh assertion  108   g , a new ninth assertion  208   j  has been added to the section  3 . 1   104 ″ of chapter  3 . In a like manner, the assertion  108   h  of section  4 . 1  of  104 ′″ in chapter  102 ′″ has remained unchanged.  
         [0118]    The revised assertion document  200 ′ includes a plurality of boxes  150 ′, W′  152 ′, X′  154 ′, Y′  156 ′, and Z′  158 ′. The box  150 ′ includes the XML representation of the first revised specification  200 , which for the most part is similar to the XML representation of the specification in the box  150  of FIG. 1A- 2 . However, the XML representation of the first revised specification as depicted in box  150 ′ contains information conveying the version of the specification. Specifically, the version number in the box  150  of FIG. 1A- 2  is shown to be “1.2_PDF1” (i.e., original specification), while the version number in the box  150 ′ is shown to be “1.2_PDF2” (i.e., the first revised specification).  
         [0119]    Reference is made to FIG. 2A- 2  depicting the XML representation of the first, second, and third assertions  108   a - c  of the first revised specification  200 , in accordance with one embodiment of the present invention. As shown, the &lt;id&gt; of each assertion has been modified so as to include the revision number “PDF2,” rather than “PDF1,” as illustrated in FIG. 1A- 3 . Furthermore, since the third assertion  108   c  has been deleted, the XML representation of the third assertion  108   c  has been changed to reflect the elimination of the assertion. Specifically, the &lt;description&gt; of the third assertion  108   c  has been changed to reflect the deprecated status of the third assertion  108   c . Furthermore, the third assertion  108   c  is marked to be &lt;assertion implementation_specific&gt;, which in one embodiment is configured to convey the behavior of the assertion. The XML representation of the third assertion  108   c  is shown in Table 17.  
                                     TABLE 17                       Exemplary XML Representation of a Deleted Assertion                                &lt;assertion&gt;       &lt;assertion implementation-specific=“true” type=“deprecated”&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF2:1:1.1:3 &lt;/id&gt;           &lt;name&gt; JSP/dynamic-content/XML &lt;/name&gt;           &lt;description&gt; deprecated &lt;/description&gt;            &lt;/assertion&gt;                  
 
         [0120]    Reference is now made to FIG. 2A- 3  in which XML representation of the fourth through sixth assertions  108   d - 108   f  of the first revised specification are shown, in accordance with one embodiment of the present invention. As discussed in more detail above, the XML representation of the sixth assertion  108   f  is modified to reflect the removal of the sixth assertion  108   f . As shown, the sixth assertion  108   f  has not been entirely removed from the representation. Simply, the description of the sixth assertion has been changed to reflect the elimination of the assertion. In one example, the eliminated assertions remain in the XML assertion document despite their eliminated status to simplify keeping track of modifications, deletions, and additions through the repeated modifications to the specification. Table 18 shows an exemplary XML representation of the sixth assertion  108   f  as deleted.  
                                                   TABLE 18                       Exemplary XML Representation of the Deleted Sixth Assertion                                    &lt;assertion implementation-specific = “true” type = “deprecated”&gt;           &lt;id&gt; Java Server Pages: 1.2_PDF2: 2:2.1:2 &lt;/id&gt;           &lt;name&gt; JSP/Protocol/HTTPS &lt;/name&gt;           &lt;description&gt; deprecated &lt;/description&gt;           &lt;depends&gt;                &lt;depend&gt; Java Server           Pages: 1.2_PDF2:2:1.1:3 &lt;/depends&gt;                &lt;/depends&gt;            &lt;/assertion&gt;                  
 
         [0121]    [0121]FIG. 2A- 4  shows the XML representation of the seventh assertion  108   g  and a new ninth assertion  208   i , in accordance with one embodiment of the present invention. The ninth assertion  208   i  has been added to the section  3 . 1   104 ″ of chapter  3  while the seventh assertion  108   g  has been deleted due to the elimination of the sixth assertion  108   f . As shown, the XML representation of the ninth assertion  208   i  easily conveys to a test developer that the ninth assertion  208   i  was not included in the initial XML representation document  100 ′ and that it has been added in the first revised specification  200 . Specifically, this information is conveyed as the &lt;id&gt; number for the ninth assertion  208   i  is higher than the &lt;id&gt; number of the seventh assertion  108   g , despite the assertion nine  208   i  being defined in the section  3 . 1   104 ″ of chapter  3   102 ″ and the seventh assertion  108   g  being defined in the section  3 . 2   110  of the chapter  3   102 ″. In the same manner, the deprecated status of the seventh assertion  108   g  informs the test developers of the elimination of the seventh assertion  108   g  in the first revised specification  200 . The XML representation of the assertions in chapter  3   102 ″ is shown below in the Table 19.  
                                                                                   TABLE 19                       Exemplary XML Representation                                &lt;assertion&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF2: 3:3.1:1 &lt;/id&gt;           &lt;name&gt; JSP/default-response-object/HHpServletResponse &lt;/name&gt;           &lt;description&gt; The default request object           is expected to extend HHpServlet            Response &lt;/description&gt;            &lt;/assertion&gt;       &lt;assertion implementation-specific = “true” type = “deprecated”&gt;                &lt;id&gt; Java Server Pages: 1.2_PDF2:3:3.2:1 &lt;/id&gt;           &lt;name&gt; JSP/default-request-object/HHpServlet Request &lt;/name&gt;           &lt;description&gt; deprecated &lt;/description&gt;           &lt;depends order = “Java Server Pages: 1.2_PDF2:1:1.1:3,                Java Server Pages: 1.2_PDF2:2:2.1:3”&gt;                  &lt;depend&gt; Java Server Pages: 1.2_PDF2:1:1.1:3 &lt;/depend&gt;             &lt;depend&gt; Java Server Pages: 1.2_PDF2:2:2.1:3 &lt;/depend&gt;                &lt;/depends&gt;            &lt;/assertion&gt;                  
 
         [0122]    [0122]FIG. 2A- 5  is the XML representation of the eight assertion  108   h  and the newly added tenth assertion  208   j , in accordance with one embodiment of the present invention. Although the eight assertion  108   h  has remained unchanged, the chapter  4   102 ′″ of the first revised specification  200  contains a new section  4 . 2   210  which includes the new tenth assertion  208   j . Again, a comparison of the XML representation of box  158 ′ and the XML representation of box  158  easily reveals that the tenth assertion  208   j  was added in the first revised specification  200 .  
         [0123]    An exemplary XML representation of a specification is shown below in Table 20.  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               TABLE 20                       Excerpts of an XML Representation of a Specification                                &lt;?xml-stylesheettype=“text/xsl”       href=“http://javaweb.sfbay/˜ja120114/xsl/assertions.xsl”?&gt;       &lt;!DOCTYPE spec SYSTEM “http://javaweb.sfbay/˜ja120114/dtds/assertions.dtd”&gt;       &lt;!-- The pattern use to define ID is: specs:version:chapter:section:local id --&gt;       &lt;spec&gt;                &lt;id&gt; JavaServerPages &lt;/id&gt;           &lt;name&gt; JavaServerPages &lt;/name&gt;           &lt;version&gt; 1.2 &lt;/version&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1 &lt;/id&gt;           &lt;name&gt; page_implementation &lt;/name&gt;           &lt;description&gt;The JSP page is compiled into a servlet&lt;/description&gt;           &lt;union&gt;                &lt;element&gt;servlet&lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2 &lt;/id&gt;           &lt;name&gt;_Actions &lt;/name&gt;           &lt;description&gt;The JSP page is composed of elements and template text,            the Action element is one them&lt;/description&gt;                &lt;union&gt;                &lt;element&gt; element/action/standard/ &lt;/element&gt;           &lt;element&gt; element/action/custom/ &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:3 &lt;/id&gt;           &lt;name&gt;_Scripting &lt;/name&gt;           &lt;description&gt;Scripting is another element that comprises the JSP            &lt;/description&gt;                &lt;union&gt;                &lt;element&gt; element/scripting/declaration &lt;/element&gt;           &lt;element&gt; element/scripting/scriptlets &lt;/element&gt;           &lt;element&gt; element/scripting/expressions &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:4 &lt;/id&gt;           &lt;name&gt;_Out &lt;/name&gt;           &lt;description&gt;The out object represent a media to flush the data out to            the user agent.&lt;/description&gt;                &lt;union&gt;                &lt;element&gt;            output_stream/JSPWriter/exposed_through_implicit_object/out_object &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:5 &lt;/id&gt;           &lt;name&gt; ExplicitObject &lt;/name&gt;           &lt;description&gt;Explicit object are Java Beans /objects that are            instantiated in the JSP&lt;/description&gt;                &lt;union&gt;                &lt;element&gt; element/explicit/server-side_object &lt;/element&gt;           &lt;element&gt; element/explicit/JavaBean &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:6 &lt;/id&gt;           &lt;name&gt;_ImplicitObject &lt;/name&gt;           &lt;description&gt;Implicit objects are available as variables that encapsulate            the basic &lt;/description&gt;                &lt;union&gt;                &lt;element&gt;jsp_page/implicit &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:7 &lt;/id&gt;           &lt;name&gt;_Attributes &lt;/name&gt;           &lt;description&gt;Attributes&lt;/description&gt;           &lt;union&gt;                &lt;element&gt; /page/element/directive/attribute &lt;/element&gt;           &lt;element&gt; /page/element/scripting/attribute &lt;/element&gt;           &lt;element&gt; /page/element/action/attribute &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:8 &lt;/id&gt;           &lt;name&gt;_ID &lt;/name&gt;           &lt;description/&gt;           &lt;union&gt;                &lt;element&gt;_Attributes/request_time/ID &lt;/element&gt;           &lt;element&gt;_Attributes/page_translation_time &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:9 &lt;/id&gt;           &lt;name&gt; StandardActionElements &lt;/name&gt;           &lt;description&gt; StandardActionElements &lt;/description&gt;           &lt;union&gt;                &lt;element&gt; jsp:useBean &lt;/element&gt;           &lt;element&gt; jsp:setProperty &lt;/element&gt;           &lt;element&gt; jsp:getProperty &lt;/element&gt;           &lt;element&gt; jsp:include &lt;/element&gt;           &lt;element&gt; jsp:forward &lt;/element&gt;           &lt;element&gt; jsp:param &lt;/element&gt;           &lt;element&gt; jsp:params &lt;/element&gt;           &lt;element&gt; jsp:plugin &lt;/element&gt;           &lt;element&gt; jsp:text &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:10 &lt;/id&gt;           &lt;name&gt; JSPDocument &lt;/name&gt;           &lt;description&gt;JSP in XML Syntax&lt;/description&gt;           &lt;union&gt;                &lt;element&gt; JSP page in XML syntax &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:11 &lt;/id&gt;           &lt;name&gt; XMLView &lt;/name&gt;           &lt;description&gt;XML view of a JSP Page&lt;/description&gt;           &lt;union&gt;                &lt;element&gt; XML document from a JSP page &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:12 &lt;/id&gt;           &lt;name&gt;_TagHandlers &lt;/name&gt;           &lt;description&gt;Tag Handlers are classes used to implement custom            actions&lt;/description&gt;                &lt;union&gt;                &lt;element&gt;element/java_classes/TagHandler/implement/Tag           &lt;/element&gt;           &lt;element&gt;           element/java_classes/TagHandler/implement/IterationTag           &lt;/element&gt;             &lt;element&gt; element/java_classes/TagHandler/implement/BodyTag &lt;/element&gt;                &lt;element&gt; element/java_interface/TagHandler/TryCatchFinally            &lt;/element&gt;                &lt;element&gt;            /jsp/page/element/java_classes/TagHandler/TagSupport &lt;/element&gt;                &lt;element&gt;            /jsp/page/element/java_classes/TagHandler/BodyTagSupport &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:13 &lt;/id&gt;           &lt;name&gt; XMLElements &lt;/name&gt;           &lt;description&gt;elements of JSP Page in XML &lt;/description&gt;           &lt;union&gt;                &lt;element&gt; jsp:root_element &lt;/element&gt;           &lt;element&gt; directive_element &lt;/element&gt;           &lt;element&gt; scripting_element &lt;/element&gt;           &lt;element&gt; standard_action_element &lt;/element&gt;           &lt;element&gt; custom_action_element &lt;/element&gt;           &lt;element&gt; jsp:text_element &lt;/element&gt;           &lt;element&gt; XML_fragments &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:14 &lt;/id&gt;           &lt;name&gt;_JavaClasses &lt;/name&gt;           &lt;description/&gt;           &lt;union&gt;                &lt;element&gt; element/java_classes/WEB-INF/lib &lt;/element&gt;           &lt;element&gt; element/java_classes/WEB-INF/classes &lt;/element&gt;           &lt;element&gt;    element/java_classes/class-path_META-            INF/MANIFEST  &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:15 &lt;/id&gt;           &lt;name&gt; IOException &lt;/name&gt;           &lt;description&gt; IOException &lt;/description&gt;           &lt;union&gt;                &lt;element&gt; java.io.IOException &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;Id&gt; JavaServerPages:1.2_PFD2:16 &lt;/id&gt;           &lt;name&gt; ClassCastException &lt;/name&gt;           &lt;description&gt; ClassCastException &lt;/description&gt;           &lt;union&gt;                &lt;element&gt; java.lang.Exception &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:17 &lt;/id&gt;           &lt;name&gt; IllegalArgumentException &lt;/name&gt;           &lt;description&gt;IllegalArgumentException &lt;/description&gt;           &lt;union&gt;                &lt;element&gt; java.lang.IllegallArgumentException &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:18 &lt;/id&gt;           &lt;name&gt; ClassCastException &lt;/name&gt;           &lt;description&gt; ClassCastException &lt;/description&gt;           &lt;union&gt;                &lt;element&gt; java.lang.ClassCastException &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:19 &lt;/id&gt;           &lt;name&gt; Instantiate &lt;/name&gt;           &lt;description&gt; Instantiate &lt;/description&gt;           &lt;union&gt;                &lt;element&gt; java.lang.InstantiateException &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;define&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:20 &lt;/id&gt;           &lt;name&gt; IllegalStateException &lt;/name&gt;           &lt;description&gt; IllegalStateException &lt;/description&gt;           &lt;union&gt;                &lt;element&gt; java.lang.IllegalStateException &lt;/element&gt;                &lt;/union&gt;                &lt;/define&gt;           &lt;chapter&gt;                &lt;id&gt; 1 &lt;/id&gt;           &lt;name&gt; The Java Server Page Technology &lt;/name&gt;           &lt;description&gt;This chapter gives an introduction to the JSP            technology&lt;/description&gt;                &lt;section&gt;                &lt;id&gt; 1.1 &lt;/id&gt;           &lt;name&gt; Introduction &lt;/name&gt;           &lt;description/&gt;           &lt;assertions&gt;                &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.1:1 &lt;/id&gt;           &lt;name&gt; /jsp/dynamic_content/HTML &lt;/name&gt;           &lt;description&gt;Java Server pages in the technology            to generate dynamic content in HTML&lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.1:2 &lt;/id&gt;           &lt;name&gt; /jsp/dynamic_content/DHTML &lt;/name&gt;           &lt;description&gt;Java Server pages in the technology            to generate dynamic content in DHTML&lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.1:3 &lt;/id&gt;           &lt;name&gt; /jsp/dynamic_content/XHTML &lt;/name&gt;           &lt;description&gt;Java Server pages in the technology            to generate dynamic content in XHTML&lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.1:4 &lt;/id&gt;           &lt;name&gt; /jsp/dynamic_content/XML &lt;/name&gt;           &lt;description&gt;Java Server pages in the technology            to generate dynamic content in XML&lt;/description&gt;                &lt;/assertion&gt;                &lt;/assertions&gt;                &lt;/section&gt;           &lt;section&gt;                &lt;id&gt; 1.2.4 &lt;/id&gt;           &lt;name&gt; Translation and Execution Steps &lt;/name&gt;           &lt;description/&gt;           &lt;assertions&gt;                &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.2.4:1 &lt;/id&gt;           &lt;name&gt; /jsp/translation &lt;/name&gt;           &lt;description&gt;The jsp pages go through a            translation and execution phase&lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.2.4:2 &lt;/id&gt;           &lt;name&gt; /jsp/execution &lt;/name&gt;           &lt;description&gt;The jsp pages go through a            translation and execution phase &lt;/description&gt;                &lt;/assertion&gt;           &lt;assertionimplementation_specific=“true“            type=“deprecated”&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.2.4:3 &lt;/id&gt;           &lt;name&gt; /jsp/translation/ &lt;/name&gt;           &lt;description&gt;deprecated&lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.2.4:4 &lt;/id&gt;           &lt;name&gt;            /jsp/container/deployment_time/translation/create_servlet &lt;/name&gt;                &lt;description&gt;The jsp pages are translated before            use to provide the web application with a servlet class that represents that page view.       The translation can be done at deployment time&lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:1:1.2.4:5 &lt;/id&gt;           &lt;name&gt;            /jsp/container/on_demand/translation/create_servlet &lt;/name&gt;                &lt;description&gt;The jsp pages are translated before            use to provide the web application with a servlet class that represents that page view.       The translation can be done on demand by the container&lt;/description&gt;                &lt;/assertion&gt;                &lt;/assertions&gt;                &lt;/section&gt;                &lt;/chapter&gt;           &lt;chapter&gt;                &lt;id&gt; 2 &lt;/id&gt;           &lt;name&gt; Core Syntax and Semantics &lt;/name&gt;           &lt;description&gt;The chapter outlines the basic syntax and elements used            in a JSP page&lt;/description&gt;                &lt;section&gt;                &lt;id&gt; 2.1 &lt;/id&gt;           &lt;name&gt; What is a JSP Page &lt;/name&gt;           &lt;description&gt;A JSP Page is a textual document that describes            how to create a response object from a request object for a given protocol. The       processing of the JSP Page may involve creating and/or using other objects.       &lt;/description&gt;                &lt;assertions&gt;                &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1:1 &lt;/id&gt;           &lt;name&gt; /jsp/protocol/HTTP &lt;/name&gt;           &lt;description&gt; HTTP is the default protocol for            requests and responses. &lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1:2&lt;/id&gt;           &lt;name&gt; /jsp/protocol/HTTPs &lt;/name&gt;           &lt;description&gt; HTTPs is the secure protocol for            requests and responses that JSP also supports. &lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1:3 &lt;/id&gt;           &lt;name&gt;            /jsp/defaut_request_object/HttpServletRequest &lt;/name&gt;                &lt;description&gt;The default request object is            expected to extend HttpServletRequest&lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1:4 &lt;/id&gt;           &lt;name&gt;            /jsp/defaut_response_object/HttpServletResponse &lt;/name&gt;                &lt;description&gt;The default request object is            expected to extend HttpServletResponse&lt;/description&gt;                &lt;/assertion&gt;                &lt;/assertions&gt;                &lt;/section&gt;           &lt;section&gt;                &lt;id&gt; 2.1.1 &lt;/id&gt;           &lt;name&gt; Web Containers and Web Components &lt;/name&gt;           &lt;description&gt; A JSP container is a system-level entity that            provides life-cycle management and runtime support for JSP Pages and Servlet       components. Here a web container is synonymous with JSP container &lt;/description&gt;                &lt;assertions&gt;                &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1.1:1 &lt;/id&gt;           &lt;name&gt;            /jsp/container/lifecycle_management/same_as_servlets &lt;/name&gt;                &lt;description&gt;The lifecycle of JSPs are same as            that of Servlets. &lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1.1:2 &lt;/id&gt;           &lt;name&gt; /jsp/container/runtime_support &lt;/name&gt;           &lt;description&gt; The JSP page uses the java            runtime environment upon which the JSP container/web server is running       &lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1.1:3 &lt;/id&gt;           &lt;name&gt;            /jsp/deployment_descriptor/implicit_jsp_extension &lt;/name&gt;                &lt;description&gt;The “.jsp“ extension is wired to a            JSP Page.&lt;/description&gt;                &lt;/assertion&gt;                &lt;/assertions&gt;                &lt;/section&gt;           &lt;section&gt;                &lt;id&gt; 2.1.2 &lt;/id&gt;           &lt;name&gt; XML Document for a JSP Page &lt;/name&gt;           &lt;description&gt; All JSP Pages have an equivalent XML            document. This is the view of the JSP Page that is exposed to the translation phase.       &lt;/description&gt;                &lt;assertions&gt;                &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1.2:1 &lt;/id&gt;           &lt;name&gt;/jsp/translation/XML_document            &lt;/name&gt;                &lt;description&gt;A JSP Page can also be written            directly as its equivalent XML document. This is delivered directly to a JSP container       for processing &lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1.2:2 &lt;/id&gt;           &lt;name&gt; /jsp/format/XML &lt;/name&gt;           &lt;description&gt; The JSP XML format should be            unique. It is not valid to intermix “standard syntax” and XML syntax inside the same       source file &lt;/description&gt;                &lt;/assertion&gt;           &lt;assertion type=“negative”&gt;                &lt;id&gt; JavaServerPages:1.2_PFD2:2:2.1.2:3 &lt;/id&gt;           &lt;name&gt;  /jsp/page/format/HTML_and_XML            &lt;/name&gt;                &lt;description&gt;HTML and XML can intermixed in            the source &lt;/description&gt;                &lt;/assertion&gt;                &lt;/assertions&gt;                &lt;/section&gt;                .           .           .                &lt;/chapter&gt;            &lt;/spec&gt;                  
 
         [0124]    [0124]FIG. 3 is a flow chart diagram  300  of method operations performed to create an XML assertion document, in accordance with one embodiment of the present invention. The method begins in operation  302  in which a software specification document to be implemented for testing is provided followed by operation  304  wherein an XML file is generated. In operation  306 , the specification portion of the specification document is tagged in the XML file. In one embodiment, tagging the specification portion includes implementing the specification document name, specification document id, specification document version, and a description of the specification document.  
         [0125]    Proceeding to operation  308 , the assertion writer goes through the specification document so as to find an assertion. By way of example, in one embodiment, the assertion can be easily identified, while in a different embodiment, the text in the specification document is analyzed to find the assertion. Thereafter, in operation  310 , the assertion is tagged in the XML file. In one example, tagging the assertion includes the assertion id, the assertion name, and the assertion description. Additional details regarding tagging the assertion has been provided above with respect to FIGS.  1 A through  2 A- 5 .  
         [0126]    Continuing to operation  312 , it is determined whether the specification document contains additional assertions to be tagged. If there are any additional assertions to be tagged, the method continues to operation  310  in which the additional assertions are tagged. If there are no additional assertions to be tagged, the method continues to operation  314  in which the Extensible Stylesheet Language (“XSLT”) is used to transform the XML file to an HTML file, thus displaying information requested by a user. In a different embodiment, XSLT Stylesheet may be used to transform the XML file into any requested format (e.g., HTML, PDF, etc.) In this manner, beneficially, substantially all information provided in the specification document can be tagged using XML. Any of the tagged information can be implemented as an index for information retrieval and display. Additionally, depending on a user&#39;s need, the tagged information can be automatically retrieved and displayed, substantially reducing the time consuming task of finding and mapping the assertions, as performed by the prior art.  
         [0127]    [0127]FIG. 4 is a flow chart diagram  400  of method operations performed to create an assertion document using a software specification document, in accordance with one embodiment of the present invention. The method begins in operation  402  in which a software specification document is reviewed to find almost all assertions. In one example, an assertion writer is configured to perform this task.  
         [0128]    Proceeding to operation  404 , each assertion in the specification document is tagged in an XML file. Then, in operation  406 , a corresponding application framework is found to exercise each of the tagged assertions. In operation  408 , a test application is generated to exercise the assertions using each of the corresponding frameworks. Each of the application frameworks implemented in the test application is mapped to the respective assertion in the specification document. Advantageously, the time consuming task of mapping the application frameworks to each of the assertions can be performed easily, thus substantially reducing time spent by each of the test developers.  
         [0129]    The advantages of the present invention are numerous. Most notably, in the embodiments of the present invention, a defined DTD can be implemented to represent substantially all possible scenarios, assertions, or requirements specification document in a given technology. In this manner, the information in a specification document can be indexed allowing retrieval of information, as needed. Another advantage of embodiments of the present invention is its capability to display the specification documents in different formats, for different purposes and as needed. Yet another advantage of the present invention is that it allows the information and document arrived at during the test development process to be shared between different groups, each having a different focus. Still another advantage of the present invention is that it allows automatic execution of software test processes for a particular feature. Still another advantage is that the present invention increases the level of the parties&#39; (e.g., managers, developers, testers, etc.) confidence on the specification, as the embodiments of the present invention can implement the indexed information to measure the specification coverage. Yet another advantage of the embodiments of the present invention is that using the keywords enables the selection and execution of a specific test having a particular feature (e.g., security, etc.)  
         [0130]    With the above embodiments in mind, it should be understood that although the present invention mainly describes exemplary embodiments of implementing XML representation of software specification documents, it must be understood by one having ordinary skill in the art that the XML representation of the present invention can be implemented to represent any document (e.g., specifications, implementation requirements, implementation design, etc.). Furthermore, although in the present invention the XML has been implemented for representing the assertions in the specification document, in a different embodiment, any suitable language capable of tagging the software documents can be implemented. Furthermore, although the embodiments of the present invention implement XSLT Stylesheet to display the assertion document, in a different embodiment, any suitable language to display the assertion document in any format desired.  
         [0131]    Additionally, it should be understood that the invention may employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing.  
         [0132]    Any of the operations described herein that form part of the invention are useful machine operations. The invention also relates to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.  
         [0133]    The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data, which can be thereafter, be read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.  
         [0134]    Furthermore, although the present invention implements Java programming language, other programming languages may be used to implement the embodiments of the present invention (e.g., C, C++, any object oriented programming language, etc.).  
         [0135]    Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.