Mechanism for debugging a computer process

Details Mechanism for debugging a computer process Mechanism for debugging a computer process

2001-10-18

2004-12-28

Iqbal, Nadeem (Department: 2114)

Error detection/correction and fault detection/recovery

Data processing system error or fault handling

Reliability and availability

C717S124000

Reexamination Certificate

active

06836857

ABSTRACT:

FIELD OF THE INVENTION
This invention relates generally to computer systems, and more particularly to a mechanism for debugging a computer process.
BACKGROUND
The XML (extensible Markup Language) specification established by the W3C Organization provides a standardized methodology for exchanging structured data between different mechanisms. The different mechanisms may be different components within the same system (e.g. different program components) or they may be completely separate systems (e.g. systems of different companies, or different servers on the Internet). Basically, XML allows structured data to be exchanged in a textual format using “element tags” to specify structure and to delimit different sets of data.
An example of a portion of an XML document is shown in FIG.
1
. In this example, information about a person is being exchanged. To indicate that the information pertains to a person, the “person” element tags are used to delimit the data. Nested within the “person” element tags are two sets of information: (1) a name; and (2) an address. These sets of information are also delimited using the “Name” and “Address” element tags, respectively. Nested within the “Name” element tags are three child elements, namely, a first, middle, and last name, each of which is delimited by respective element tags, and each of which has an associated value. Likewise, nested within the “Address” element tags are four child elements, namely, a street, city, state, and zip code, each of which is delimited by respective element tags, and each of which has an associated value. By delimiting the sets of data using nested element tags in this manner, the XML document makes it clear how the data is structured, and what each set of data represents. As a result, any mechanism that is capable of understanding the element tags used to delimit the data will be able to interpret and process the data. In this manner, XML makes it possible to exchange structured data in a textual, program-independent, and platform-independent manner. It is this general nature of XML that makes it so flexible and versatile. Because of its versatility, XML has grown significantly in popularity in recent years. The above discussion provides just a brief description of the XML specification. More information on XML may be found on the W3C website at www.w3c.org. All of the information on that website, as of the filing date of the present application, is incorporated herein by reference.
In some instances, before data in an XML document can be processed or rendered, the XML document first needs to be transformed. For example, if the information of the person shown in
FIG. 1
is to be rendered on a cellular phone display, and the cellular phone display does not have enough room for a middle name, then the XML document may first need to be transformed by removing the “middle” name element before the information is provided to the cellular phone to be displayed. As another example, the element tag used in one system may differ from the element tag used in another system. For example, the “person” element tag in one system may correspond to the “employee” element tag in another system. Before the XML document is processed into the other system, the XML document is first transformed to change the “person” element tag to an “employee” element tag. These are examples of simple transformations that can be made to an XML document. Many other more complex transformations may also be made.
To enable an XML document (referred to as a source document) to be transformed into another document (referred to as a result document), there is currently provided a transformation language, known as XSLT (extensible stylesheet language transformation). Using XSLT, a transformation document (also referred to as a stylesheet) can be created which, when processed together with the source document, gives rise to the result document. In effect, the transformation document specifies the transformations that need to be made to the source document to derive the result document. For example, the transformation document may specify that whenever a “person” element tag is encountered in the source document, an “employee” element tag should be created in the target document. According to the XSLT specification (which is provided in the W3C website), the transformation document is itself an XML document; thus, it conforms to all of the requirements to which all XML documents conform.
Typically, a transformation document is created by a developer or an end user who wishes to perform a desired set of transformations on one or more source documents. Once developed, the transformation document is provided to a transformation processor, along with one or more source documents, for processing. In response, the transformation processor applies the transformations specified in the transformation document to the elements in the source document to derive a result document. If all goes well, the result document will contain all of the desired transformations and have the exact form that the user desires. This is often not the case, however. Because XSLT is a fairly complex language, users often make mistakes in creating the transformation document. This in turn leads to undesired results in the result document. Typically, a transformation processor provides as output just the result document and no other information. Given only the result document, the source document, and the transformation document, it is very difficult if not almost impossible for a user to determine what part of the transformation document gave rise to the undesired results. As a result, the user does not know what portion or portions of the transformation document to change to correct the problem. As this discussion shows, it is currently very difficult to debug a transformation document. Accordingly, a mechanism for facilitating the debugging process is needed.
SUMMARY OF THE INVENTION
In accordance with one embodiment of the present invention, there is provided a mechanism for facilitating the debugging of a computer process. In one embodiment, a debugging mechanism is provided which interacts with a user interface to enable a user to specify one or more breakpoints. These breakpoints indicate to the debugging mechanism where processing of a source document and a transformation document should halt to enable a user to view the results generated up to that point. In one embodiment, the user may specify a breakpoint at a particular location in the transformation document or the source document. In addition, the user may specify one or more breakpoints using a conditional expression (e.g. an Xpath expression in accordance with the Xpath specification on the W3C website). This expression is later evaluated to determine whether a breakpoint has been reached. Furthermore, a breakpoint may be specified based upon XSL messages. In one embodiment, the debugging mechanism maintains all of the breakpoint specifications provided by the user for later evaluation.
In addition to interacting with the user interface, the debugging mechanism also interacts with a transformation processor, which is the mechanism that actually processes the source and transformation documents to derive the result document. In one embodiment, before and after each processing action, the transformation processor sends a pre-action and a post-action message, respectively, to the debugging mechanism. Along with these messages, the transformation processor also references some context information pertaining to the processing action that is about to be performed or that has just been performed. This context information indicates what portion of each document the transformation processor is processing. After sending each message, the transformation processor waits for a response from the debugging mechanism.
In reaction to each message, the debugging mechanism uses the context information referenced in the message to determine whether any of the breakpoints have been reached. If no breakpoint has been reached, then the debugging m

Affiliated with

Also associated with

Rating

Mechanism for debugging a computer process does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Mechanism for debugging a computer process, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Mechanism for debugging a computer process will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3305443