SCRIPTING LANGUAGE FOR NETWORK FUNCTIONS

Abstract: The invention is a Network Query Language, comprising a scripting language for performing functions on computer networks. The language is interpreted and is oriented toward the development of intelligent agents, bots, spiders, and Internet applications. Features supported by the present invention include full interoperability with the World Wide Web; features for unattended operation; features for distributed processing; features to categorize information; communication and conversion capabilities; and the ability to read and write XML. The invention supports instructions to launch and control a web browser. Navigation, waiting for responses, entry of input fields, submission of forms, and clicking of links can all be controlled by a script written in the Network Query Language. This allows any action that can be done on the web interactively to be automated, with a high likelihood of success.

Description: SCRIPTING LANGUAGE FOR NETWORK FUNCTIONS BACKGROUND OF THE INVENTION Field of the Invention This invention relates to the field of scripting languages. In particular, the invention relates to scripting languages designed for performing queries on computer networks. Description of the Related Art The amount of information on the Internet and within the corporate enterprise continues to expand at an astonishing rate, while a human being's ability to digest data is fixed. There is an undeniable need for machines to operate on behalf of humans, processing information in a highly automated and customized fashion. The information overload problem grows worse every day. Software agents - or bots - are automated programs, which accomplish tasks that are inefficient, difficult or impossible to tackle manually. Often they are created to obtain, manipulate and communicate information between machines, and can be highly sophisticated - or "intelligent" - traveling across networks with their creators' wisdom propelling them, and learning along the way. Trustworthy agents will increasingly serve as information filters, data monitors, alert/notification systems and automatic response systems. The need for agents is only going to increase with time, as the demand for information to be exchanged around the globe, regardless of technology platforms, formats and systems, continues to proliferate. The tasks facing the modern programmer are quite different from the past, even as recent as five years ago. New kinds of software entities are in demand, such as bots. intelligent agents, and middleware. Today's solutions are expected to interoperate with the outside world, perhaps via the Web or e-mail. Today's solutions are also expected to interoperate with the corporate intranet, perhaps acquiring information from a legacy system or converting information to a popular desktop office format. Programmers are expected to understand and be able to intermix all of this technology, like a spider perched in the center of a Web. Development tasks have never been more demanding, yet the time allotted for projects continues to decrease. Conventional programming languages lack the built-in functions that modern software needs. Most programming languages provide important primitives like file input/output and arithmetic functions, but today such things as remote file delivery and pattern matching are just as vital. Because traditional languages lack the essentials of the connected age, developers are forced to write programs that are larger than necessary, which leads to projects that take longer to develop than is necessary. A lot of duplication occurs as programmers re-invent the wheel, implementing functionality that their development tools lack. The lack of an agent-oriented language means a senior programmer is often required to create such projects. Existing languages, such as Java and Perl, do not adequately address the need of modern networked environments. PERL is often used for Web server applications for the simple reason that it is less deficient in Internet access and parsing than most traditional languages; nevertheless, it is not an ideal language for agent development. It has a cryptic syntax left over from the UNIX world, and much of its functionality comes from modules rather than discrete features of the language. Java does offer platform independence and automatic garbage collection, but aside from that it is practically identical to C++ — and offers no agent-oriented features. It's just as laborious to filter e-mail or interpret data from a Web page in Java as it is in C++. There is a need for "network" query language", to do for network programming what SQL did for database programming. Such a language would not necessarily resemble SQL in grammar, but would contain the built-in functions to interact transparently with the Internet, desktop applications, e- mail. databases, and legacy systems. SUMMARY OF THE INVENTION The invention is a Network Query Language, comprising a scripting language for performing functions on computer networks. The language is interpreted and is oriented toward the development of intelligent agents, bots, spiders, and Internet applications. Features supported by the present invention include full interoperability with the World Wide Web; features for unattended operation; features for distributed processing; features to categorize information; communication and conversion capabilities; the ability to read and write XML. The invention supports instructions to launch and control a web browser. Navigation, waiting for responses, entry of input fields, submission of forms, and clicking of links can all be controlled by a script written in the Network Query Language. This allows any action that can be done on the web interactively to be automated, with a high likelihood of success. An embodiment of the invention contains direct features for unattended operation. One embodiment contains an at statement, which waits for a specific date/time, or time of day, before executing the remainder of its script. at " 3 : 00pm" ...code to execute at 3:00 pm... Another embodiment contains an every statement, which repeats a biock of code at regular intervals. every " 0 : 15 " { ...code to execute every 15 minutes... Embodiments of the invention aiso support features to wait until a specific event is satisfied before executing. The checkpagewait statement, for example, waits until a specific web site changes before proceeding. The present invention also includes a strong set of communications protocols, including the following: HTTP, HTTPS, FTP, NNTP, LDAP, POP3, SMTP, MAPI, ODBC, OLEDB, SOAP, and WAP. An embodiment of the invention includes a method of parsing an XML document by use of a scripting language. The embodiment involves generating a script in the scripting language, wherein the script containing a set of instructions for retrieving and parsing the XML document; executing the script, including pushing XML from the document onto a stack data structure and identifying a first XML node in a top of the stack in response to a first instruction in the script. In embodiments of the invention, a second XML node is identified in the top of the stack in response to a second instruction in the script. Embodiments of the invention include scripting language for posting and retrieving information over a computer network. In some embodiments, the scripting language includes instructions for accessing and posting messages via POP3, SMTP, and MAPI protocols; instructions for parsing XML code; instructions for automating completion of web-based forms; instructions for communicating via the group of protocols consisting of HTTP, HTTPS, FTP, NNTP, LDAP, POP3, SMTP, ODBC, OLEDB. SOAP, and WAP. In an aspect of the embodiment, the scripting language is interpreted line-by-line. The scripts may be executed in multiple threads operating in parallel. In embodiments of the invention, the multiple threads may execute on separate processors distributed over a computer network. In embodiments of the invention, the scripting language includes an instruction for spawning new processes. In some embodiments, a first script executing the instruction in a first process may launch a second script in a second process. The first process and second process reside in a first processor and a second processor, respectively. The first processor and the second processor may be coupled by a computer network, such as a LAN. WAN. or Internet. In embodiments of the invention, the first process and the second process communicate via a named pipe. In some embodiments, the processes executing scripts in the language can lock or unlock resources on a computer network. BRIEF DESCRIPTION OF THE FIGURES Fig. 1 illustrates a stack data structure used by instructions in the scripting language in an embodiment of the invention. Fig. 2 illustrates a push operation performed on the stack by instructions in the scripting language. Fig 3. Illustrates a pop operation performed on the stack by instructions in the scripting language. Fig 4. Lists a set of operators supported by the scripting language in an embodiment of the invention. Fig 5. Illustrates a multi -threaded script written in the scripting language in an embodiment of the invention. DETAILED DESCRIPTION A. Introduction The present invention comprises a scripting language, or Network Query Language (NQL), for creating intelligent agents for use in computer networks. The scripting language is designed to make it easy to create intelligent agents on the network. It contains built-in features for Internet/network communications. including, but not limited to database I/O, pattern matching, and the interchange of information with XML. NQL is a scripting language, not a programming language. A scripting language is meant for small, simple scripts that are interpreted and run on the fly. As contrasted with complete programming languages, scripting languages are easier to use for their intended purpose and do not require pre-compilation with development tools. B. Capabilities of the Network Query Language NQL is concerned with moving information between different places and transforming it along the way. NQL contains these inborn capabilities: Internet/network communications Web site crawling/spidering functions Database communications E-mail communications Terminal emulation Directory server lookup • Delimited data I/O Interfacing with/exporting to desktop applications Image creation and manipulation File and directory operations XML input/output operations, parsing, and validation • HTML/XML parsing Pattern matching Multi-threaded parallel processing Desktop agent characters/avatars Text-to-speech • Multimedia playing Inter-process messaging Exporting Accessing objects on remote systems Network monitoring • Wireless device application support These capabilities are further described infra. The specific commands supported by the present invention, along with their implementations, are also described in Provisional Application Nos. 60/124, 699, filed March 15. 1999 entitled "A Method for Facilitating Queries Over a Computer Network": 60/127.363, filed April 1. 1999 entitled "Scripting Tools for Network Functions"; Application No. 60/129.138, filed April 13. 1999 entitled "Scripting Tools for Network Functions"; and to an application filed March 14, 2000 entitled "Network Query Language", inventor David Pallman, Attorney Docket No. 17314-712, and which are herein incorporated by reference in their entirety. C. Working with the Stack NQL maintains a stack of variable-length data chunks. Some statements in the language depend on the stack. The stack-oriented design makes recursive operations simpler, such as crawling a web site. NQL primarily uses the stack for string (text) storage, but the stack can also hold binary data. Any item on the stack is flagged as text or binary. Coercion between data types is automatic as needed. In some cases, an NQL statement operates differently on a text value on the stack compared to a binary value on the stack. The stack is a "last in, first out" pile of values, illustrated in Figure 1. Usually, only the top-most value 102 on the stack 100 (the last item added to the stack) is visible. If the top-most item 102 is removed from the stack, the item that had been below it 104 becomes visible. Adding a new value to the stack is called a push operation. Removing a value from the stack is called a. pop operation. The push statement, illustrated in Figure 2, pushes a value 200 onto the stack 202, so that the value 200 is visible on the post-operation stack 204: push "CA" push sName The pop statement, illustrated in Figure 3. removes a value 300 from the top of the stack 302. A pop without an argument discards the value. A pop with a variable name stores the value in a variable 306. In both cases, the top-most value is removed from the post-operation stack 304. pop pop When iterating through all values in the stack, it is often necessary to determine when the stack is empty. The empty statement sets the success/failure flag to allow conditional jumping: // display and remove all items on the stack Loop : empty then Done show pop goto Loop Done : By default, a stack item may be as large as 256K. This limit is under script control: the datasize statement may be used to change the maximum size of a stack item. D. Rules of Syntax in the Network Query Language Statements Statements are commands to NQL. An NQL program consists of zero or more statements. Statement Form All statements consist of a command verb. Depending on the command verb, an argument may be mandatory, optional, or disallowed. Examples: get "http: //www. nσlsolutions . com" match "<form>{ or Sec ioni </form>" FormSection Single-line Statements NQL statements generally appear on a single line. There is no special end-of-statement character. get "http : / /www . nqlsciutions . com" White space characters (tabs, spaces, newlines) may be used freely, such as to control indenting, but a statement's command verb and ts argument, if any, must appear on the same line. Multiple Statements On The Same Line At times, it may be desirable to specify multiple statements on a single line for style or readability. The sequence " : " (space-colon-space) may be used to separate statements on a single line. The example below contains four statements, three of which are combined on line 2. get "http: //www. search. co /query?keywords=belt" push : match "<form>{ FormSection></form>" : pop Continuation Lines The NQL script parser automatically deduces the fact that a statement may continue on to additional lines. There are two conditions under which this automatic continuation to the next line occurs: (1) unterminated literals and (2) statement lines that end in an operator. Unterminated literals An unterminated quoted string auto-continues to the next line until complete. Example: match "<head> <tιtle> </tιtle> </head>" Dangling Operators A statement ending in an operator implies continuation. Example: tax = amount * tax_rate Comments Lines beginning with the semi-colon character ( ; ) or double forward slash (/ /) are considered to be comment lines. Blank lines and comment lines are ignored. Example: / / submit the search request get "http : / /www . search . com/query . dll ?keywords=camera" ; this is also a comment The comment character (If) may also appear at the end of any statement. output sResults // all done! Arguments NQL statements have no arguments or a single argument. At least one space or tab must separate a command verb from its argument. An argument may be: • A variable name • A literal, which is either a string enclosed in quotation marks or a numeric value • A stack reference Literal Arguments There is no difference between a quoted numeric literal and a direct numeric literal. In other words. " 183". '183', and 183 are the same to the script interpreter, and all three evaluate as string literals. The unquoted form of numbers is permitted as a style convenience to programmers. You can use single quote or double quotes as a string delimiter. This provide maximum flexibility when the data must contain one type of quote or the other, as in "O ' Malley ' s " or "His name was ' Jerry ' " Escape Sequences in Literals The backslash character (\) has specfal meaning in a string literal. A backslash followed by digits is taken as a decimal character code. "This is a letter: \65!" is the same as "This is a letter: A! " There are also a variety of non-digit characters that may follow a backlash, which are also discussed in Provisional Application Nos. 60/124, 699, filed March 15, 1999 entitled "A Method for Facilitating Queries Over a Computer Network"; 60/127,363, filed April 1. 1999 entitled "Scripting Tools for Network Functions"; Application No. 60/129.138. filed April 13, 1999 entitled "Scripting Tools for Network Functions"; and to an application filed March 14, 2000 entitled "Network Query Language", inventor David Pallman, Attorney Docket No. 17314-712, which are all herein incorporated by reference in their entirety. Variable Name Arguments A variable name begins with a letter and may contain letters, digits, and special symbols that are not operators, such as the underscore. If the variable refers to an element of an array, an integer or variable appears at the end enclosed in square brackets, as in x [ 5 j or Month [ ] . Because NQL freely maps variables with database fields, web forms, and pattern matching, it is sometimes necessary to express an NQL variable that is technically illegal. For example, an NQL variable cannot normally contain dash (-) or underscore (_), because those are operators. Square brackets may be used to enclose variable names that bend the rules: [full-name] = last & ", " & first show [full-name] Stack Reference Arguments The single dot ( . ) and double dot ( . J) are interpreted as stack references. A single dot is the top-most stack value. A double-dot is the next-to- topmost stack value. These values can be used anywhere that a literal or variable value would be expected. Examples: get "http : / /www . nqlsolutions . com" string literal pop SearchResults variable name push 17 "numeric" literal show . . stack reference Variables, literals, and stack references can be combined with operators to create expressions. show SubTotal + Tax push Category I " ( " I Subcategory I " ) " x = . / . . Case Sensitivity In general, NQL is a case-insensitive language. Variation in case does not affect recognition of keywords or variable names. However, the case sensitivity of NQL's string and pattern matching functions is under the control of the programmer. String comparisons are case-insensitive by default; the case statement is used to set the case sensitivity. Variables All NQL variables are variable-length strings. Some operators interpret strings as numeric values and perform arithmetic operations, but ultimately all data is stored as text strings. Variables may be simple variables or elements of one-dimensional arrays. Implicit Variable Declaration NQL does not require variables to be declared in advance. Once a variable name is used for the first time, storage is allocated and the variable's value is initialized to an empty string. Explicit Variable Declaration For programmers who prefer to declare all variables in advance, the var keyword may be used. The var keyword is followed by the name of the variable being declared. Storage is allocated for the variable and its value is initialized to an empty string. var Open var Last var Change var Volume var Symbol[100] Variable Creation Variables are created when declared or the first time they are referenced in any way. Variable Destruction Unless the program explicitly destroys a variable (using the destroy statement), a variable remains allocated until the program completes execution. All variable memory is freed when an NQL program exits. Assignment Whenever the assignment operator is used, a variable is created or updated with a new value. Assignment can be an incidental result of an expression. The example statement below displays a value on the screen, but also assigns values to variables: show subtotal, tax = succotal * tax_rate, total = subtotai+tax Assignment statements can appear by themselves rather than being part of the arguments for other statements. The statement below only sets a variable value and performs no other action. state = "CA" Expressions Any time that a single value is required for an NQL statement, an expression may appear in its place. An expression is multiple values separated by operators. In the example below, the first statement has a single argument while the second and third statements have expressions. show "The s cript is complete . " show 52 * 100 show "Welcome back, " I sFirst ι " " I sLast Operators Operators appear between two values. After the operator executes, a single value replaces the two values. Many operators accepts a variable or a literal on either side of the operator. However, some operators are assignment- oriented and expect only a variable name on the left side of the operator. A summary of the operators appears in the table 400 contained in Figure 4. The table 400 lists operators 402 alongside descriptions 404 and what they operators evaluate to 406. Labels Labels indicate a control flow location in a program. Labels are declared by specifying a label name and a colon. Labels appear on a line by themselves. Example: Loop: match "<TD>{valueK/TD>" err Done output value goto Loop Done : The Stack NQL maintains a stack for string values. The topmost value on the stack is used and/or modified by many statements. Directives Directives begin with a pound-sign (#) and issue special instructions to the compiler. #include The #include directive, followed by a space and a file specification, reads in a disk file as part of the source code. Example: #include c:\library\quote.nql E. Parallel Processing in the Network Query Language The present invention includes facilities for distributed processing, such as threading and spawning multiple processes. Multithreading NQL contains features that promote distributed processing. One such feature is multi -threading. A single NQL script can execute blocks of codes in additional threads of execution, allowing parallel execution of code. The example below is also illustrated in Figure 5. The script 500, shown below accesses four different web sites 502 504 506 508 by spawning four threads 510 512 514 516. Patterns of matching data are found from each site and output to a common XML stream. The four sites are accessed all at the same time, in parallel, which greatly reduces the script's execution time thread { URL1 = "...url..." Patternl = "...pattern..." get URL1 matchall Patternl } thread { URL2 = "...url..." Pattern2 = "...pattern..." get URL2 matchall Pattern2 1 thread { URL3 = "...url..." Patterns = "...pattern..." get URL3 matchall Pattern3 } thread { URL4 = "...url..." Pattern4 = "...pattern..." get URL4 matchall Pattern4 waitallthreads Spawing A Thread The thread statement identifies a block of code to be executed in parallel. The example below visits a web site 100 times and measures the accuracy and timeliness of each response, all in parallel: for i = 1, 100 { thread { get "www.cnn.com" then match sExpecteαResponse then results = "hit the site (expected response ) else results = "hit the site (unexpecteα response > " pop results = "connection failed" elapsedtime responsetime output " ( responsetime } \t ( esults } \n" } } Thread IDs Threads may be given ID numbers, which is useful when managing and synchronizing multiple threads. thread 1 ( get "www.quote.com" ticker = "MSFT" submit save "quotel.htm" } thread 2 ticker = "MSFT" submit save "quote2.htm" In the example shown in Figure 5. each thread 510 512 514 516 has a respective Thread ID 518 520 522 524. Thread Synchronization When an NQL scripts finishes execution, it waits for any spawned worker threads to complete before terminating. To specifically wait for a thread to finish, the waitthread statement may be used. // collect data in parallel thread 1 ( get "www.quote.com'' ticker = "MSFT" submit save "quotel.htm" thread 2 get www.pcquote.com symBols = "MSFT" submit save "quote2.htm" // wait till all data has been collected waitthread 1 waitthread 2 load "quotel.htm" load "quote2.htm" Spawning Processes An additional feature for distributed processing is the ability to spawn separate processing. NQL's run statement allows a separate script to be launched in a separate process. The example below shows a script named parti that launches a second script, part2, in the midst of its processing. parti .nql part2.nql ...script loads... ...execution... run "part 2 . nql " ...script loads... ...execution... ...execution... Process-to-process Communication Distributed processes should be able to communicate and to share resources. Named pipes allow communication between agent scripts, whether on the same computer or separate computers. The sample code below shows an agent opening a communication pipe to another agent and sending it a message. openpipe "netmon.pip" sendpipe " 999-Fιnxshed" closepipe Resource Sharing. Agents can share resources using mutexes. serializing access to lockable resources. The code below shows a script gaining access to a lock before deleting a file. If the lock is in use. the script waits for its availability before continuing. lock "logfile" append sLogFile write "Process completed with no errors" close unlock "logfile" Scaleability. The distributed processing features mentioned above make NQL extremely scaleable. A lone NQL script can run on a desktop. To handle a greater workload, a script can be run in multiple instances on large server or even distributed across multiple servers. Scripts with different tasks can communicate with each other to work in cooperation. F. XML Support in the Network Query Language NQL can work with extensible Markup Language (XML) in a variety of ways. This chapter provides a tour of how NQL and XML can be used together. Types of XML The XML standard recognizes two levels of XML documents: "well- formed XML" and "valid XML". Valid XML is syntactically correct and specifies a Document Type Definition (DTD) that allows the document to be validated for proper structure. Well-formed XML is syntactically correct but does not have a DTD to verify against. The present invention considers a third variant of XML showing up in enterprises, which we'll call "simple XML". In Simple XML. XML tags and values are used to interconnect applications and components without using some of XML's harder-to-parse features, such as parameter values within tags. For those who wish to parse XML directly, simple XML is relatively simple to process whereas a processor that supports all of XML is a much more difficult proposition. Without taking sides on the merits of each. NQL contains features for working with well-formed XML, valid XML, and simple XML. The XML Input Stream All NQL scripts can receive a standard input, which is expected to be simple XML by default. When developing interactively with the NQL desktop client, XML input can be specified by selecting View > Inputs from the menu. When calling NQL programmatically, the calling program can specify an input stream prior to requesting execution of a script. When calling an NQL script that is a web application, URL parameters and form fields are mapped to XML for the script. So no matter what environment it is accessed from, an NQL script can receive XML as input. Inputting Data Fields The NQL input statement retrieves fields from the XML input stream. The parameters specified to input are one or more variable names. input CustI D, CompanyName , EmailAddress For each variable specified, input attempts to locate XML tags with matching names. For example, the above statement tries to find <CustI D>... < /CustI D>, <CompanyName>...</CompanyName>. and <EmailAddress>...</EmailAddress> tags in the input stream. The values are mapped to the specified variables. In the above example, the NQL script has values to work with in Cust I D, CompanyName. and EmailAddress. Inputting Multiple Records of Data Fields There may be a need to repeatedly retrieve sets of records from the input stream. This is the purpose of the inputrecord statement, inputrecord finds a set of tags that enclose values to be used for subsequent input statements. Each time inputrecord is repeated, a new set of values is set in focus from the XML input stream. For example, consider the XML input stream below. <product> <id>l</idxdesc>wιdget</desc><prιce>100 . 00</pπce> </product> <product> <id>2</idxdesc>sprocket</desc><price>15 . 00</price> </product> To process a product at a time, the inputrecord statement can be used as shown below to isolate each <product>... < /product> section. Then, the input statement can be used to retrieve id, desc, and price from the current product. inputrecord "product" while { input id, desc, price show id, desc, price inputrecord "product" } Formal Processing The input and inputrecord statements are often sufficient for working with XML input, but there may be a need to formally parse and validate XML input. In such cases, the thing to do is capture the input stream on the stack (with getinput) and open the XML for parsing (with openxml). The specifics of formal XML parsing are described infra. // process the input XML stream formally getinput openxml closexml The XML Output Stream NQL scripts can generate an output stream, which may be XML as well as other formats. Outputting Data Fields The output statement adds to the output stream. It can be called with a variable list, or with an expression. When output is called with a variable list, each variable's name and values are output as XML. first = "George" last = "Washington" order = 1 output first, last, order The above code adds the following to the XML output stream: <first>George</first> <last>Washington</last> <order>K/order> When output is called with an expression, rather than a variable list, the specified value is written out directly without any special XML formatting. outputrecord "< ! This is a comment>" Outputting Multiple Records of Data Fields When working with records of fields, there is a need to include enclosing tags around data fields to show record grouping. The outputrecord statement performs this logical grouping. The example below reads President records from a database. As the select and nextrecord statements set variable values based on the current database record, outputrecord and output are used to send the values to the output stream formatted as XML records. select "SELECT first, last, order FROM Presidents;" while { outputrecord "President" output first, last, order nextrecorα) A fragment of the output from the above script is shown below. <Presιdent> <first>George</fιrst> <last>Washington</last> <order>K/order> </President> <Presιdent> <first>John</first> <last>Adams</last> <order>2</order> </Presιdent> <Presιdent> <first>Thomas</first> <last>Jefferson</last> <orcter>3</order> </Presιdent> XML Parsing NQL is able to parse XML documents formally and perform validation. Under Windows, this requires the presence of Microsoft's XML parser. MSXML, which is available for free from Microsoft. Throughout these sections, we'll use the sample XML below for purposes of illustration. <?xml versιon="1.0" , > <'DOCTYPE list [ < < ELEMENT recipe (autnor, recιpe_name, meal, ingredients, directions ) > < ' ELEMENT ingredients ιtem+)> <> ELEMENT meal '#PCDATA)> <' ELEMENT item (--PCDATA) > <' ELEMENT recιpe_πame <#PCDATA)> < 'ELEMENT author * PCDATA) > <> ELEMENT directions (#PCDATA<> < ' ELEMENT list (recipe ^ > 1 > .iιst> <recιpe> <autnor type=" mαιvιαual ">Carol Scnmιdt< /autnor> recιpe_name>Cnoco ate Ohio Bars< / recipe name> <meai>Dιnner </meal> <mgredιents> <ιtem>2/3 C butter</ιtem> <ιtem>2 C brown sugar</ιtem> <ιtem>l tsp vanιlla</ιtem> <ιtem>l 3/4 C unsifted all-purpose flour</ιtem> <ιtem>l 1/2 tsp baking powder</ιtem> <ιtem>l/2 tsp salt</ιtem> <ιtem>3 eggs</ιtem> <ιtem>l/2 C chopped nuts</ιtem> <ιtem>2 cups (12-oz pκg.( semi-sweet choc. chιps</ιtem> </ingredients> <dιrectιons> Preheat oven to 350 degrees. Melt butter; combine with brown sugar and vanilla in large mixing bowl. Set aside to cool. Combine flour, baking powder, and salt; set aside. Add eggs to cooled sugar mixture; Deat well. Stir in reserved dry ingredients, nuts, and chips. Spread in greased 13-by-9-mch pan. Bake for 25 to 30 minutes until golden brown; cool. Cut into squares. </dιrectιons> </recιpe> <recιpe> <author type="mdιvιdual">Carol Schmιdt</author> <recιpe_name>Pasta with tomato Sauce</recιpe name> <meal>Dιnner </meal> <ιngreαιents> <ιtem->l -.a spaαnettκ/ιtem> <ιtem>l 16-oz can diced tomatoes</ιtem> <ιtem>4 cloves σarlιc</ ιtem> <ιteπι>i diced onιon</ιtem> <ιtem>Italιan seasonmg</item> </mgredιents> <dιrectιons> Boil pasta. Saute garlic and onion. Add tomatoes. Serve hot. </dιrect ons> </recipe> </iιst> Opening an XML Parsing Session To begin parsing operations, the first step is to-issue an openxml statement. The URL or file specification of an XML document is usually specified as an argument. openxml "http : //www.myserver . com/bizdocs/neworders . xml" Sometimes the XML to be parsed is on the stack, having already been acquired from a remote source. Specifying openxml without any arguments pops the top item off of the stack as its source XML. openxml Validation XML document validation is automatic. When an XML document is opened with openxml. any specified validation occurs automatically. If openxml returns a success condition, then either the XML validates against a DTD, or no DTD is specified in the XML. Finding a Node By Name To move to a specific section of an XML document, all you need to know is the name of the enclosing XML tag. The f irstnode statement finds the first instance of the specified tag name, and makes its contents the focus for subsequent XML processing. Using the XML sample that appears at the start of this section, one can move to the first recipe using the following statement: firstnode " recipe " This sets the focus to the first recipe record. Extracting Values To retrieve values from a node that has focus, the getnode statement is used. A variable list is specified. Each variable name is used to locate an XML tag, and the results are stored in the listed variables. firstnode " recipe " getnode author , recipename , meal , author . type Note the use of a dot in the above example for author . type. The dot notation lets you go one level deeper in the current focus in the XML. Since XML values may include white space, it's frequently a good idea to use the trim statement to remove leading and trailing spaces, tabs, and newline characters. trim author , recipename , meal , author . type Advancing to the Next Node firstnode only takes you to the first instance of a named node. To move on to the next instance, the nextnode statement is used. openxml "recipies . xml" firstnode "recipe" while { getnode author, recipename, meal, author. type trim author, recipename, meal, author. type show author, recipename.- meal, author, type nextnode "recipe" } closexml Nesting Nodes Once you set the focus to an area of the XML (with firstnode or nextnode), you can repeat the process and set a finer focus within that segment of XML. For example, the code below works with each "recipe" at an outer level, but within each recipe also iterates through its ingredient list. openxml "recipies . xml" firstnode "recipe" while { getnode author, recipename, meal, autnor.type trim author, recipename, meal, author. type show author i "\n" i recipename ι "\n" I meal ! "\n" I author. ype firstnode "ingredients . item" while { getnode item show recipename '\n\n" ! item nextnode " ingredients . item" closenode nextnode "recipe" } closexml end Note the use of closenode in the above code, closenode is what shuts down the inner level of focus (the ingredients list), returning focus out one level back (to the current recipe). Closing an XML Parsing Session The closexml statement terminates XML parsing and frees resources used during the parsing. closexml G. Using Simple Object Access Protocol (SOAP) The Simple Object Access Protocol (SOAP) permits enterprises to communicate with each other abstractly using just HTTP and XML. Since HTTP and XML are universally available. SOAP can be deployed with no disruption to an organization's network and firewalls. With SOAP, two organizations with completely different architectures can interoperate at a high level. For example, a company running on the Windows DNA architecture with mostly Windows NT systems can cleanly work with a company using CORBA on Sun Solaris systems via SOAP. NQL has client SOAP support, which means that NQL scripts can invoke methods on remote systems that support SOAP. This is a form of remote procedure call. How SOAP Works To access a remote method, the caller provides the following: 1. The URL of the HTTP server to be accessed 2. The name of the method (procedure) to invoke on the remote system. 3. Parameters which the remote method needs, formatted as XML. This is known as the XML payload. The SOAP request is passed to the remote system as an HTTP POST request. with special SOAP-specific headers, and the XML payload as the data area. After passing the SOAP request to the remote system. XML response data is received, which contains the results from the remote method. Making SOAP Requests in NQL NQL has a getob j ect statement that makes a SOAP request. Prior to calling getobject, the XML payload for the request is pushed onto the stack. For example, the code below pushes the payload for one of Microsoft's example SOAP functions, reverse_string. push ' <SerializedStream SerializationPattern="urn : schemas- microsof t-com: soap : vl " headers="#ref-0 " maιn="#ref- l "xheaders id="ref- 0"xinterfaceName>soap : cdl : com. develop . demos . string_test</ Interf aceNameX/headersxreverse_string id="ref- 1 "x param0> ! dlrow olleH</ paramOx/reverse_strιngX/SerιalizedStream> ' After pushing the payload XML onto the stack, getobj ect can be invoked, getobj ect needs the URL of the HTTP server, the method name to invoke, and a third optional parameter is the interface name to specify to the SOAP server. getobj ect "http : //soap . develop . com/sd2 /vbasperl . soap " , "reverse_string" , "soap : cdl : com. develop . demos . string_test " getobj ect creates the necessary HTTP headers and makes a SOAP request, popping the XML payload off of the stack. If the request is successfully completed, a success condition results, and XML response data is left on the stack. You can test for success/failure using then and else code blocks. getobject url, method, interface then { show "it worked" ; else { show "it failed" } Processing The Response Data The response information from a successful SOAP request is XML. which is left on the stack in place of the XML payload that was previously there. You can work with this XML in a few different ways: 1. To process the XML using the simple XML input stream primitives (input and inputrecord), issue a setinput statement. This pops the XML off of the stack and makes it it the input stream. Then, use input or inputrecord statements to retrieve values. push payload getobj ect url , "ConvertCoordinate " then { input x , y , units } 2. To process the XML formally, issue an openxml statement with no arguments. This uses the top stack value as the source XML. Use firstnode, nextnode. and getnode statements to set focus and extract values. push payload getobj ect url , "Li stOpenOrders " then { openxml firstnode " order " while { nextnode " order " } closexml 3. SOAP methods may include a specific "return value" for a method, which is often the one piece of the response data you may be interested in. NQL automatically finds and maps this value for you, under the variable name MethodRetum. For example, if you called a method named Translate, the return value will be in the variable TranslateReturn. push payload getobject url, "Translate" then { show "The result is " & TranslateReturn } H. Conclusion The foregoing description of various embodiments of the invention has been presented for purposes of illustration and description. It is not intended to limit the invention to the precise forms disclosed. Many modifications and equivalent arrangements will be apparent.

Claims: CLAIMS What is claimed is: 1. A method of parsing an XML document by use of a scripting language, the method comprising: generating a script in the scripting language, the script containing a set of instructions for retrieving and parsing the XML document; executing the script, including pushing XML from the document onto a stack data structure, in response to a first instruction in the script, identifying a first XML node in a top of the stack. 2. The method of claim 1 , further comprising: parsing the first node, including identifying a first plurality of values contained in the first node storing the first plurality of values in a first plurality of variables. 3. The method of claim 2, further comprising: in response to a second instruction in the script, identifying a second XML node in the top of the stack. 4. The method of claim 3, further comprising: parsing the second node, including identifying a second plurality of values contained in the second node storing the second plurality of values in a second plurality of variables. 5. A scripting language for posting and retrieving information over a computer network, the scripting language including: instructions for accessing and posting messages via POP3. SMTP, and MAPI protocols: instructions for parsing XML code; instructions for automating completion of web-based forms: instructions for communicating via the group of protocols consisting of HTTP, HTTPS, FTP, NNTP, LDAP, POP3, SMTP, ODBC, OLEDB, SOAP, and WAP. 6. The scripting language of claim 5, wherein the scripting language is interpreted line-by-line. 7. The scripting language of claim 5, wherein the scripting language allows scripts to be executed in multiple threads operating in parallel. 8. The scripting language of claim 7, wherein the multiple threads may execute on separate processors distributed over a computer network. 9. The scripting language of claim 8, wherein the computer network is a LAN. 10. The scripting language of claim 8. wherein the computer network is a WAN. 11. The scripting language of claim 8, wherein the computer network is the Internet. 12. The scripting language of claim 5, further including: an instruction for spawning new processes. 13. The scripting language of claim 12. wherein a first script executing the instruction in a first process launches a second script in a second process. 14. The scripting language of claim 13. wherein the first process and second process reside in a first processor and a second processor, respectively. 15. The scripting language of claim 14, wherein the first processor and the second processor are coupled by a computer network. 16. The scripting language of claim 15, wherein the computer network is one of a LAN, WAN, or Internet. 17. The scripting language of claim 16. wherein the first process and the second process communicate via a named pipe. 18. The scripting language of claim 14. wherein the first process and the second process communicate via a named pipe. 19. The scripting language of claim 5. wherein processes executing scripts in the language can lock or unlock resources on a computer network. 20. A method of executing a script encoded in a multi -threaded scripting language, the method comprising: executing a first thread, the first thread including a first set of instructions from the script; executing a second thread, the second thread including a second set of instructions from the script, wherein the second script runs in parallel to the first script. 21. The method of claim 20, further comprising: waiting for completion of the first thread and the second thread; executing a remaining portion of the script. 22. The method of claim 20, wherein the first thread and the second thread are processed by a first processor and a second processor, respectively. 23. The method of claim 22, wherein the first and second processors are in communication on a computer network. 24. The method of claim 23, wherein the computer network is one of a LAN, WAN, or the Internet. 25. The method of claim 5. wherein the scripting language is interpreted line-by-line. 26. A computer system for performing queries on a computer network, the computer system comprising: a communications channel: a plurality of processors in communication via the communications channel; a scripting language accessible to the plurality of processors; a script written in the scripting language, the script including a plurality of threads, wherein each of the plurality of threads is executed on a separate processor in the plurality of processors. 27. The computer system of claim 26. wherein the scripting language is interpreted line-by-line. 28. The computer system of claim 27, wherein the communications channel is one of a LAN. WAN or the Internet.

Inventors: PALLMAN DAVID, PALLMAN, DAVID
Applicants: ALPHA MICROSYSTEMS INC, PALLMAN DAVID, ALPHA MICROSYSTEMS, INC., PALLMAN, DAVID
Application year: 2000
Main classification: G06F9
IPC codes: G06F9