Benchmark: test DomParser with medium HTML string

Tests:

Dom Parser
const html = ` <html> <head>  <title>Large HTML page with images</title>  <link href="htmlparser/sections.css" rel="stylesheet" type="text/css">  </head> <body> <div align="center"><center> <h1 class="fore">When to load CSS</h1> <table border="0" cellspacing="5" width="100%" bgcolor="#F2F2FF"> <tr> <td>Large HTML page with Images</td> </tr> </table> </center></div> <hr> This page shall test if the recorder generates scripts with requests in correct order. It includes images in sequential order: stadyn_image1.gif through stadyn_image10.gif <hr> <img src="stadyn_image1.gif" width="70" height="70" alt="stadyn_image1.gif (6512 bytes)"> stadyn_image1 <img src="stadyn_image2.gif" width="70" height="70" alt="stadyn_image2.gif (5983 bytes)"> stadyn_image2 Open Financial Exchange Specification 1.0 February 14, 1997 © 1997 CheckFree Corp., Intuit Inc., Microsoft Corp. All rights reserved Chapters 1 - 10 <h1><img src="stadyn_image3.gif" width="70" height="70" alt="stadyn_image3.gif (6537 bytes)"> stadyn_image3</h1> <h1><img src="stadyn_image4.gif" width="70" height="70" alt="stadyn_image4.gif (6028 bytes)"> stadyn_image4</h1> <img src="stadyn_image5.gif" width="70" height="70" alt="stadyn_image5.gif (4068 bytes)"> stadyn_image5     <h1><a NAME="_Toc371408167">Contents</a></h1> 1. Overview 51.1 Introduction 51.1.1 Design Principles 51.2 Open Financial Exchange at a Glance 71.2.1 Data Transport 71.2.2 Request and Response Model 81.3 Conventions 92. Structure 102.1 HTTP Headers 102.2 Open Financial Exchange Headers 112.2.1 The Meaning of Version Numbers 122.3 SGML Details 122.3.1 Compliance 122.3.2 Special Characters 122.4 Open Financial Exchange SGML Structure 132.4.1 Overview 132.4.2 Top Level 132.4.3 Messages 132.4.4 Message Sets and Version Control 142.4.5 Transactions 152.5 The Signon Message Set 162.5.1 Signon <SONRQ> <SONRS> 162.5.2 PIN Change <PINCHRQ> <PINCHRS> 192.5.3 Examples 202.6 External Data Support 202.7 Extensions to Open Financial Exchange 213. Common Aggregates, Elements, and Data Types 223.1 Common Aggregates 223.1.1 Identifying Financial Institutions and Accounts 223.1.2 Balance Records <BAL> 223.1.3 Error Reporting <STATUS> 233.2 Common Elements 243.2.1 Financial Institution Transaction ID <FITID> 243.2.2 Server-Assigned ID <SRVRTID> 243.2.3 Client-Assigned Transaction UID <TRNUID> 253.2.4 Token <TOKEN> 253.2.5 Transaction Amount <TRNAMT> 253.2.6 Memo <MEMO> 253.2.7 Date Start and Date End <DTSTART> <DTEND> 263.3 Common data types 263.3.1 Dates and Times 263.3.2 Amounts, Prices, and Quantities 283.3.3 Language 283.3.4 Basic data types 284. Security 294.1 Security Solutions 294.1.1 Determining Security Levels <OFXSEC> <TRANSPSEC> 294.2 Channel-Level Security 304.2.1 Security Requirements 304.2.2 Using SSL 3.0 in Open Financial Exchange 304.3 Application-Level Security 314.3.1 Requirements for Application-Layer Security 314.3.2 Using Application-level Encryption in Open Financial Exchange 325. International Support 335.1 Language and Encoding 335.2 Currency <CURDEF> <CURRENCY> <ORIGCURRENCY> 335.3 Country-Specific Tag Values 346. Data Synchronization 356.1 Overview 356.2 Background 356.3 Data Synchronization Approach 366.4 Data Synchronization Specifics 376.5 Conflict Detection and Resolution 396.6 Synchronization vs. Refresh 406.7 Typical Server Architecture for Synchronization 416.8 Typical Client Processing of Synchronization Results 436.9 Simultaneous Connections 446.10 Synchronization Alternatives 446.10.1 Lite Synchronization 446.10.2 Relating Synchronization and Error Recovery 456.11 Examples 467. FI Profile 487.1 Overview 487.1.1 Message Sets 487.1.2 Version Control 497.1.3 Batching and Routing 497.2 Profile Request 507.3 Profile Response 517.3.1 Message Set 527.3.2 Signon Realms 537.3.3 Status Codes 537.4 Profile Message Set Profile Information 548. Activation & Account Information 558.1 Overview 558.2 Approaches to User Sign-Up with Open Financial Exchange 558.3 Users and Accounts 568.4 Enrollment and Password Acquisition <ENROLLRQ> <ENROLLRS> 568.4.1 User IDs 578.4.2 Enrollment Request 578.4.3 Enrollment Response 598.4.4 Enrollment Status Codes 598.4.5 Examples 608.5 Account Information 608.5.1 Request <ACCTINFORQ> 618.5.2 Response <ACCTINFORS> 618.5.3 Account Information Aggregate <ACCTINFO> 628.5.4 Status Codes 628.5.5 Examples 638.6 Service Activation 638.6.1 Activation Request and Response 648.6.2 Service Activation Synchronization 668.6.3 Examples 668.7 Name and Address Changes <CHGUSERINFORQ> <CHGUSERINFORS> 678.7.1 <CHGUSERINFORQ> 678.7.2 <CHGUSERINFORS> 688.7.3 Status Codes 688.8 Signup Message Set Profile Information 699. Customer to FI Communication 709.1 The E-Mail Message Set 709.2 E-Mail Messages 709.2.1 Regular vs. Specialized E-Mail 719.2.2 Basic <MAIL> Aggregate 719.2.3 E-Mail <MAILRQ> <MAILRS> 719.2.4 E-Mail Synchronization <MAILSYNCRQ> <MAILSYNCRS> 729.2.5 Example 739.3 Get HTML Page 749.3.1 MIME Get Request and Response <GETMIMERQ> <GETMIMERS> 749.3.2 Example 759.4 E-Mail Message Set Profile Information 7610. Recurring Transactions 7710.1 Creating a Recurring Model 7710.2 Recurring Instructions <RECURRINST> 7710.2.1 Values for <FREQ> 7810.2.2 Examples 7910.3 Retrieving Transactions Generated by a Recurring Model 8010.4 Modifying and Canceling Individual Transactions 8010.5 Modifying and Canceling Recurring Models 8010.5.1 Examples 81 <ol> <li><a NAME="_Toc380493239">Overview</a> </li> <li><a NAME="_Toc380493240">Introduction</a> </li> </ol> Open Financial Exchange is a broad-based framework for exchanging financial data and instructions between customers and their financial institutions. It allows institutions to connect directly to their customers without requiring an intermediary. Open Financial Exchange is an open specification that anyone can implement: any financial institution, transaction processor, software developer or other party. It uses widely accepted open standards for data formatting (such as SGML), connectivity (such as TCP/IP and HTTP), and security (such as SSL). Open Financial Exchange defines the request and response messages used by each financial service as well as the common framework and infrastructure to support the communication of those messages. This specification does not describe any specific product implementation. <ol> <li><a NAME="_Toc380493241">Design Principles</a> </li> </ol> The following principles were used in designing Open Financial Exchange: l Broad Range of Financial Activities - Open Financial Exchange provides support for a broad range of financial activities. Open Financial Exchange 1.0 specifies the following services: n Bank statement download n Credit card statement download n Funds transfers including recurring transfers n Consumer payments, including recurring payments n Business payments, including recurring payments n Brokerage and mutual fund statement download, including transaction history, current holdings and balances l Broad Range of Financial Institutions - Open Financial Exchange supports communication with a broad range of financial institutions (FIs), including: n Banks n Brokerage houses n Merchants n Processors n Financial advisors n Government agencies l Broad Range of Front-End applications - Open Financial Exchange supports a broad range of front-end applications covering all types of financial activities running on all types of platforms, including Web-based applications. l Extensible - Open Financial Exchange has been designed to allow the easy addition of new services. Future versions will include support for many new services. l Open - This specification is publicly available. You can build client and server applications using the Open Financial Exchange protocols independent of any specific technology, product, or company. l Multiple Client Support - Open Financial Exchange allows a user to use multiple client applications to access the same data at a financial institution. With the popularity of the World Wide Web, customers are increasingly more likely to use multiple applications-either desktop-based or Web-based-to perform financial activities. For example, a customer can track personal finances at home with a desktop application and occasionally pay bills while at work with a Web-based application. The use of data synchronization to support multiple clients is a key innovation in Open Financial Exchange. l Robust - Open Financial Exchange will be used for executing important financial transactions and for communicating important financial information. Assuring users that transactions are executed and information is correct is crucial. Open Financial Exchange provides robust protocols for error recovery. l Secure - Open Financial Exchange provides a framework for building secure online financial services. In Open Financial Exchange, security encompasses authentication of the parties involved, as well as secrecy and integrity of the information being exchanged. l Batch & Interactive - The design of request and response messages in Open Financial Exchange is for use in either batch or interactive style of communication. Open Financial Exchange provides for applying a single authentication context to multiple requests in order to reduce the overhead of user authentication. l International Support - Open Financial Exchange is designed to supply financial services throughout the world. It supports multiple currencies, country-specific extensions, and different forms of encoding such as UNICODE. l Platform Independent -Open Financial Exchange can be implemented on a wide variety of front-end client devices, including those running Windows 3.1, Windows 95, Windows NT, Macintosh, or UNIX. It also supports a wide variety of Web-based environments, including those using HTML, Java, JavaScript, or ActiveX. Similarly on the back-end, Open Financial Exchange can be implemented on a wide variety of server systems, including those running UNIX, Windows NT, or OS/2. l Transport Independent - Open Financial Exchange is independent of the data communication protocol used to transport the messages between the client and server computers. Open Financial Exchange 1.0 will use HTTP. <ol> <li><a NAME="_Toc380493242">Open Financial Exchange </a>at a Glance </li> </ol> The design of Open Financial Exchange is as a client and server system. An end-user uses a client application to communicate with a server at a financial institution. The form of communication is requests from the client to the server and responses from the server back to the client. Open Financial Exchange uses the Internet Protocol (IP) suite to provide the communication channel between a client and a server. IP protocols are the foundation of the public Internet and a private network can also use them. <ol> <li><a NAME="_Toc380493243">Data Transport</a> </li> </ol> Clients use the HyperText Transport Protocol (HTTP) to communicate to an Open Financial Exchange server. The World Wide Web throughout uses the same HTTP protocol. In principle, a financial institution can use any off-the-shelf web server to implement its support for Open Financial Exchange. To communicate by means of Open Financial Exchange over the Internet, the client must establish an Internet connection. This connection can be a dial-up Point-to-Point Protocol (PPP) connection to an Internet Service Provider (ISP) or a connection over a local area network that has a gateway to the Internet. Clients use the HTTP POST command to send a request to the previously acquired Uniform Resource Locator (URL) for the desired financial institution. The URL presumably identifies a Common Gateway Interface (CGI) or other process on an FI server that can accept Open Financial Exchange requests and produce a response. The POST identifies the data as being of type application/x-ofx. Use application/x-ofx as the return type as well. Fill in other fields per the HTTP 1.0 spec. Here is a typical request: <pre> POST http://www.fi.com/ofx.cgi HTTP/1.0 User-Agent:MyApp 5.0 Content-Type: application/x-ofx Content-Length: 1032 OFXHEADER:100 DATA:OFXSGML VERSION:100 SECURITY:1 ENCODING:USASCII <OFX> ... Open Financial Exchange requests ... </OFX> </pre> A blank line defines the separation between the HTTP headers and the start of the actual Open Financial Exchange data. A blank line also separates the Open Financial Exchange headers and the actual response. (See Chapter 2, for more information.) The structure of a response is similar to the request, with the first line containing the standard HTTP result, as shown next. The content length is given in bytes. <pre> HTTP 1.0 200 OK Content-Type: application/x-ofx Content-Length: 8732 OFXHEADER:100 DATA:OFXSGML VERSION:100 SECURITY:1 ENCODING:USASCII <OFX> ... Open Financial Exchange responses ... </OFX> </pre> <ol> <li><a NAME="_Toc380493244">Request and Response</a> Model </li> </ol> The basis for Open Financial Exchange is the request and response model. One or more requests can be batched in a single file. This file typically includes a signon request and one or more service-specific requests. An FI server will process all of the requests and return a single response file. This batch model lends itself to Internet transport as well as other off-line transports. Both requests and responses are plain text files, formatted using a grammar based on Standard Generalized Markup Language (SGML). Open Financial Exchange is syntactically similar to HyperText Markup Language (HTML), featuring tags to identify and delimit the data. The use of a tagged data format allows Open Financial Exchange to evolve over time while continuing to support older clients and servers. Here is a simplified example of an Open Financial Exchange request file. (This example does not show the Open Financial Exchange headers and the indentation is only for readability.) For complete details, see the more complete examples throughout this specification. <OFX>  <SIGNONMSGSRQV1> <SONRQ>  <DTCLIENT>19961029101000  <USERID>123-45-6789  <USERPASS>MyPassword  <LANGUAGE>ENG  <FI>  <ORG>NCH  <FID>1001  </FI> <APPID>MyApp <APPVER>0500 </SONRQ>  </SIGNONMSGSRQV1> <BANKMSGSRQV1> <STMTTRNRQ>  <TRNUID>1001 <STMTRQ>  <BANKACCTFROM>  <BANKID>121099999  <ACCTID>999988  <ACCTTYPE>CHECKING  </BANKACCTFROM>  <INCTRAN>  <INCLUDE>Y  </INCTRAN>  </STMTRQ>  </STMTTRNRQ>  </BANKMSGSRQV1></OFX> The response format follows a similar structure. Although a response such as a statement response contains all of the details of each transaction, each element is identified using tags. The key rule of Open Financial Exchange syntax is that each tag is either an element or an aggregate. Data follows its element tag. An aggregate tag begins a compound tag sequence, which must end with a matching tag; for example, <AGGREGATE> ... </AGGREGATE>. The actual file Open Financial Exchange sends is without any extra white space between tags. <ol> <li><a NAME="_Toc380493245">Conventions</a> </li> </ol> The conventions used in the detailed descriptions include: <ul> <li>Required tags are in bold. Regular face indicates tags that are optional. Required means that a client will always include a tag in a request, and a server must always include a tag in a response. </li> <li>Italic shows a required or optional aggregate from a set of possible aggregates. </li> <li>Required tags occur once unless noted as one or more in the description, in which case the specification allows multiple occurrences. </li> <li>Optional tags occur once if present unless noted as zero or more in the description, in which case the specification allows multiple occurrences. </li> <li>Allowable specific values are listed, where applicable. </li> <li>A-n or N-n, specify those values that take general alphanumeric or pure numeric type values, where n indicates the maximum size. </li> <li>References to certain common value types, such as a dollar amount, are by name. Chapter 3 lists value types that can be referenced by name. </li> </ul> <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="162">Tag </td> <td BGCOLOR="#000000" WIDTH="336">Description </td> </tr> <tr> <td WIDTH="162"><REQUIREDTAG> </td> <td WIDTH="336">Required tag (1 or more) </td> </tr> <tr> <td WIDTH="162"><REQUIREDTAG2> </td> <td WIDTH="336">Required tag that occurs only once </td> </tr> <tr> <td WIDTH="162"><OPTIONALTAG> </td> <td WIDTH="336">Optional tag; this particular one can occur multiple times (0 or more) </td> </tr> <tr> <td WIDTH="162"><SPECIFIC></td> <td WIDTH="336">Values are A, B, and C </td> </tr> <tr> <td WIDTH="162"><ALPHAVALUE></td> <td WIDTH="336">Takes an alphanumeric value up to 32 characters, A-32 </td> </tr> </table> <ol> <li><a NAME="_Toc380493246">Structure</a> </li> </ol> This chapter describes the basic structure of an Open Financial Exchange request and response. Structure includes headers, basic syntax, and the Signon request and response. This chapter also describes how Open Financial Exchange encodes external data, such as bit maps. Open Financial Exchange data consists of some headers plus one or more Open Financial Exchange data blocks. Each block consists of a signon message and zero or more additional messages. When sent over the internet using HTTP, standard HTTP and multi-part MIME headers and formats surround the Open Financial Exchange data. A simple file that contained only Open Financial Exchange data would have the following form: <pre> HTTP headers MIME type application/x-ofx Open Financial Exchange headers Open Financial Exchange SGML block 1 </pre> A more complex file that contained multiple Open Financial Exchange data blocks and additional Open Financial Exchange data would have this form: <pre> HTTP headers MIME type multipart/x-mixed-replace; boundary =--boundary- ---boundary--- MIME type application/x-ofx Open Financial Exchange headers Open Financial Exchange SGML block 1 Open Financial Exchange SGML block 2 ---boundary--- MIME type image/jpeg FI logo </pre> <ol> <li><a NAME="_Toc380493247">HTTP Headers</a> </li> </ol> Data delivered by way of HTTP places the standard HTTP result code on the first line. HTTP defines a number of status codes. Servers can return any standard HTTP result. However, FIs should expect clients to collapse these codes into the following three cases: <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="84">Code </td> <td BGCOLOR="#000000" WIDTH="96">Meaning </td> <td BGCOLOR="#000000" WIDTH="312">Action </td> </tr> <tr> <td WIDTH="84">200</td> <td WIDTH="96">OK </td> <td WIDTH="312">The request was processed and a valid Open Financial Exchange result is returned. </td> </tr> <tr> <td WIDTH="84">400s</td> <td WIDTH="96">Bad request </td> <td WIDTH="312">The request was invalid and was not processed. Clients will report an internal error to the user. </td> </tr> <tr> <td WIDTH="84">500s</td> <td WIDTH="96">Server error </td> <td WIDTH="312">The server is unavailable. Clients should advise the user to retry shortly. </td> </tr> </table> NOTE: Open Financial Exchange returns a code 400 only if it cannot parse the file. Open Financial Exchange handles content errors such as wrong PIN, or invalid account, by returning a valid Open Financial Exchange response along with code 200. Open Financial Exchange requires the following HTTP standard headers: <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="84">Code </td> <td BGCOLOR="#000000" WIDTH="96">Value </td> <td BGCOLOR="#000000" WIDTH="312">Explanation </td> </tr> <tr> <td WIDTH="84">Content-type</td> <td WIDTH="96">application/x-ofx </td> <td WIDTH="312">The MIME type for Open Financial Exchange </td> </tr> <tr> <td WIDTH="84">Content-length</td> <td WIDTH="96">length </td> <td WIDTH="312">Length of the data after removing HTTP headers </td> </tr> </table> <pre> </pre> When responding with multi-part MIME, the main type will be multi-part/x-mixed-replace; one of the parts will use application/x-ofx. <ol> <li><a NAME="_Toc380493248">Open Financial Exchange Headers</a> </li> </ol> The intent of Open Financial Exchange is for use with a variety of transports and to provide sufficient version control capabilities for future expansion. To support this goal, the contents of an Open Financial Exchange file consist of a simple set of headers followed by contents defined by that header. "File format" means the entire content after removal of any transport headers. The HTTP transport described in this document, means without the HTTP and MIME headers. The Open Financial Exchange headers are in a simple tag:value syntax and terminated by a blank line. Open Financial Exchange always sends headers unencrypted, even if there is application-level encryption in use for the remaining contents. The first entry will always be OFXHEADER with a version number. This entry will help identify the contents as an Open Financial Exchange file, and provides the version of the Open Financial Exchange headers that follow (not of the content itself). For example: <pre> OFXHEADER:100 </pre> This document defines version 1.0 of the headers to contain at least the following additional tags: <pre> DATA:OFXSGML VERSION:100 SECURITY: ENCODING: CHARSET: COMPRESSION: OLDFILEUID: NEWFILEUID: </pre> The data tag identifies the contents as being in OFX SGML form. VERSION identifies the version type as OFXSGML data. In the case of OFXSGML, it translates to the version of the Document Type Definition (DTD) that it uses for parsing. The ENCODING and CHARSET tags define the interpretation of the character data. See Chapter 5, "International Support" for more information on these tags. Chapter 4 describes the security tag. A future version of this specification will define compression. Open Financial Exchange uses OLDFILEUID and NEWFILEUID to support error recovery. They are not present when clients are not requesting error recovery. (See Chapter 6, "Data Synchronization") A blank line follows the last tag. Then (for type OFXSGML), the SGML-readable data begins with the <OFX> tag. NOTE: Here, VERSION provides the overall version of the DTD. The <OFX> block describes the specific message set versions used, shown later in this chapter. <ol> <li><a NAME="_Toc380493249">The Meaning of Version Numbers</a> </li> </ol> The OFXHEADER value should only change its major number if an existing client is unable to process the new header. This can occur because of a complete syntax change in a header, or a significant change in the semantics of an existing tag-not the entire response. You can add new tags as long as clients can function without understanding them. You should add new values for a data tag only when you introduce an entirely new syntax. In the case of OFXSGML, a new syntax would have to be non-SGML compliant to warrant a new data value. It is possible that there will be more than one syntax in use at the same time to meet different needs. The intent of the header version tag is to identify syntactic changes. In the case of OFXSGML, this corresponds to the DTD. Purely for identification purposes, each change will increment the minor number of the version tag. If you introduce an incompatible change so that an older DTD can not parse the file, the major number will change. See the general discussion of message sets and version control, later in this chapter. <ol> <li><a NAME="_Toc380493250">SGML Details</a> </li> <li><a NAME="_Toc380493251">Compliance</a> </li> </ol> SGML is the basis for Open Financial Exchange. There is a DTD that formally defines the SGML wire format. However, Open Financial Exchange is not completely SGML-compliant because the specification allows unrecognized tags to be present. It requires clients and servers to skip over the unrecognized material. That is, if <XYZ>qqq</XYZ> appeared and a client or server cannot recognize <XYZ>, the server should ignore that tag and its enclosed data. A fully-compliant SGML parser would not validate an Open Financial Exchange document if it contained any tags that the DTD does not define. Although SGML is the basis for the specification, and the specification is largely compliant with SGML, do not assume Open Financial Exchange supports any SGML features not documented in this specification. The intent is to allow parsing to be as simple as possible, while retaining compatibility with the SGML world. <ol> <li><a NAME="_Toc380493252">Special Characters</a> </li> </ol> The following characters are special to SGML. Use the given alternative sequence to represent them: <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="162">Character </td> <td BGCOLOR="#000000" WIDTH="336">Escape sequence </td> </tr> <tr> <td WIDTH="162">< (less than)</td> <td WIDTH="336">&lt; </td> </tr> <tr> <td WIDTH="162">> (greater than)</td> <td WIDTH="336">&gt;</td> </tr> <tr> <td WIDTH="162">& (ampersand)</td> <td WIDTH="336">&amp; </td> </tr> </table> For example, the string "AT&amp;T" encodes "AT&T." A special case applies in specific tags that can accept HTML-formatted strings, such as e-mail records. These accept SGML marked section syntax to hide the HTML from the Open Financial Exchange parser. You must prefix strings with "<![ CDATA ["and suffixed with"]]>." Within these bounds, treat the above characters literally without an escape. See the Chapter 9 for an example. <ol> <li><a NAME="_Toc380493253">Open Financial Exchange SGML Structure</a> </li> <li><a NAME="_Toc380493254">Overview</a> </li> </ol> Open Financial Exchange hierarchically organizes request and response blocks: Top Level <OFX> Message Set and Version <XXXMSGSVn> Synchronization Wrappers <YYYSYNCRQ>, <YYYSYNCRS> Transaction Wrappers <YYYTRNRQ>, <YYYTRNRS> Specific requests and responses The following sections describe each of these levels. <ol> <li><a NAME="_Toc380493255">Top Level</a> </li> </ol> An Open Financial Exchange request or response has the following top-level form: <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="162">Tag </td> <td BGCOLOR="#000000" WIDTH="336">Description </td> </tr> <tr> <td WIDTH="162"><OFX></td> <td WIDTH="336">Opening tag</td> </tr> <tr> <td WIDTH="162">... Open Financial Exchange requests or responses ... </td> <td WIDTH="336">0 or more transaction requests and responses inside appropriate message set aggregates </td> </tr> <tr> <td WIDTH="162"></OFX></td> <td WIDTH="336">Closing tag for the Open Financial Exchange record </td> </tr> </table> This chapter specifies the order of requests and responses. A single file can contain multiple <OFX> ... </OFX> blocks. A typical use of multiple blocks is to request in a single file information associated with different users. <ol> <li><a NAME="_Toc380493256">Messages</a> </li> </ol> A message is the unit of work in Open Financial Exchange. It refers to a request and response pair, and the status codes associated with that response. For example, the message to download a bank statement consists of the request <STMTRQ> and the response <STMTRS>. In addition, with the exception of the signon message, each message includes a transaction wrapper. These aggregates add a transaction unique ID <TRNUID>, and for responses, a <STATUS> aggregate, to the basic request and response. For messages subject to synchronization (see Chapter 6), a third layer of aggregates is also part of a message definition: a synchronization request and response. These add a token and, in some cases, other information to the transactions. Open Financial Exchange uses the following naming where the XXX message includes: <ul> <li>Basic request <XXXRQ> and response <XXXRS> </li> <li>Transaction wrapper <XXXTRNRQ> and <XXXTRNRS> </li> <li>If needed, synchronization wrapper <XXXSYNCRQ> and <XXXSYNCRS> </li> </ul> In a few cases, a small number of related basic requests and responses share a transaction and synchronization wrapper. The term message will still apply to each request and response; only the naming scheme will not hold in those cases. <ol> <li><a NAME="_Toc380493257">Message Sets and Version Control</a> </li> </ol> Message sets are collections of messages. Generally they form all or part of what a user would consider a service, something for which they might have signed up, such as "banking." Message sets are the basis of version control, routing, and security. They are also the basis for the required ordering in Open Financial Exchange files. Within an Open Financial Exchange block, Open Financial Exchange organizes messages by message set. A message set can appear at most once within an Open Financial Exchange block. All messages from a message set must be from the same version of that message set. For each message set of XXX and version n, there exists an aggregate named <XXXMSGSVn>. (Compare with <XXXMSGSETVn> in Chapter 7.) All of the messages from that message set must be inside the appropriate message set aggregate. In the following example, the Open Financial Exchange block contains a signon request inside the signon message set, and two statement requests and a transfer request inside the bank message set. </body> </html> `; const parser = new DOMParser(); const virtualDom = parser.parseFromString(html, 'text/html'); const body = virtualDom.querySelector('body');
Regex
const html = ` <html> <head>  <title>Large HTML page with images</title>  <link href="htmlparser/sections.css" rel="stylesheet" type="text/css">  </head> <body> <div align="center"><center> <h1 class="fore">When to load CSS</h1> <table border="0" cellspacing="5" width="100%" bgcolor="#F2F2FF"> <tr> <td>Large HTML page with Images</td> </tr> </table> </center></div> <hr> This page shall test if the recorder generates scripts with requests in correct order. It includes images in sequential order: stadyn_image1.gif through stadyn_image10.gif <hr> <img src="stadyn_image1.gif" width="70" height="70" alt="stadyn_image1.gif (6512 bytes)"> stadyn_image1 <img src="stadyn_image2.gif" width="70" height="70" alt="stadyn_image2.gif (5983 bytes)"> stadyn_image2 Open Financial Exchange Specification 1.0 February 14, 1997 © 1997 CheckFree Corp., Intuit Inc., Microsoft Corp. All rights reserved Chapters 1 - 10 <h1><img src="stadyn_image3.gif" width="70" height="70" alt="stadyn_image3.gif (6537 bytes)"> stadyn_image3</h1> <h1><img src="stadyn_image4.gif" width="70" height="70" alt="stadyn_image4.gif (6028 bytes)"> stadyn_image4</h1> <img src="stadyn_image5.gif" width="70" height="70" alt="stadyn_image5.gif (4068 bytes)"> stadyn_image5     <h1><a NAME="_Toc371408167">Contents</a></h1> 1. Overview 51.1 Introduction 51.1.1 Design Principles 51.2 Open Financial Exchange at a Glance 71.2.1 Data Transport 71.2.2 Request and Response Model 81.3 Conventions 92. Structure 102.1 HTTP Headers 102.2 Open Financial Exchange Headers 112.2.1 The Meaning of Version Numbers 122.3 SGML Details 122.3.1 Compliance 122.3.2 Special Characters 122.4 Open Financial Exchange SGML Structure 132.4.1 Overview 132.4.2 Top Level 132.4.3 Messages 132.4.4 Message Sets and Version Control 142.4.5 Transactions 152.5 The Signon Message Set 162.5.1 Signon <SONRQ> <SONRS> 162.5.2 PIN Change <PINCHRQ> <PINCHRS> 192.5.3 Examples 202.6 External Data Support 202.7 Extensions to Open Financial Exchange 213. Common Aggregates, Elements, and Data Types 223.1 Common Aggregates 223.1.1 Identifying Financial Institutions and Accounts 223.1.2 Balance Records <BAL> 223.1.3 Error Reporting <STATUS> 233.2 Common Elements 243.2.1 Financial Institution Transaction ID <FITID> 243.2.2 Server-Assigned ID <SRVRTID> 243.2.3 Client-Assigned Transaction UID <TRNUID> 253.2.4 Token <TOKEN> 253.2.5 Transaction Amount <TRNAMT> 253.2.6 Memo <MEMO> 253.2.7 Date Start and Date End <DTSTART> <DTEND> 263.3 Common data types 263.3.1 Dates and Times 263.3.2 Amounts, Prices, and Quantities 283.3.3 Language 283.3.4 Basic data types 284. Security 294.1 Security Solutions 294.1.1 Determining Security Levels <OFXSEC> <TRANSPSEC> 294.2 Channel-Level Security 304.2.1 Security Requirements 304.2.2 Using SSL 3.0 in Open Financial Exchange 304.3 Application-Level Security 314.3.1 Requirements for Application-Layer Security 314.3.2 Using Application-level Encryption in Open Financial Exchange 325. International Support 335.1 Language and Encoding 335.2 Currency <CURDEF> <CURRENCY> <ORIGCURRENCY> 335.3 Country-Specific Tag Values 346. Data Synchronization 356.1 Overview 356.2 Background 356.3 Data Synchronization Approach 366.4 Data Synchronization Specifics 376.5 Conflict Detection and Resolution 396.6 Synchronization vs. Refresh 406.7 Typical Server Architecture for Synchronization 416.8 Typical Client Processing of Synchronization Results 436.9 Simultaneous Connections 446.10 Synchronization Alternatives 446.10.1 Lite Synchronization 446.10.2 Relating Synchronization and Error Recovery 456.11 Examples 467. FI Profile 487.1 Overview 487.1.1 Message Sets 487.1.2 Version Control 497.1.3 Batching and Routing 497.2 Profile Request 507.3 Profile Response 517.3.1 Message Set 527.3.2 Signon Realms 537.3.3 Status Codes 537.4 Profile Message Set Profile Information 548. Activation & Account Information 558.1 Overview 558.2 Approaches to User Sign-Up with Open Financial Exchange 558.3 Users and Accounts 568.4 Enrollment and Password Acquisition <ENROLLRQ> <ENROLLRS> 568.4.1 User IDs 578.4.2 Enrollment Request 578.4.3 Enrollment Response 598.4.4 Enrollment Status Codes 598.4.5 Examples 608.5 Account Information 608.5.1 Request <ACCTINFORQ> 618.5.2 Response <ACCTINFORS> 618.5.3 Account Information Aggregate <ACCTINFO> 628.5.4 Status Codes 628.5.5 Examples 638.6 Service Activation 638.6.1 Activation Request and Response 648.6.2 Service Activation Synchronization 668.6.3 Examples 668.7 Name and Address Changes <CHGUSERINFORQ> <CHGUSERINFORS> 678.7.1 <CHGUSERINFORQ> 678.7.2 <CHGUSERINFORS> 688.7.3 Status Codes 688.8 Signup Message Set Profile Information 699. Customer to FI Communication 709.1 The E-Mail Message Set 709.2 E-Mail Messages 709.2.1 Regular vs. Specialized E-Mail 719.2.2 Basic <MAIL> Aggregate 719.2.3 E-Mail <MAILRQ> <MAILRS> 719.2.4 E-Mail Synchronization <MAILSYNCRQ> <MAILSYNCRS> 729.2.5 Example 739.3 Get HTML Page 749.3.1 MIME Get Request and Response <GETMIMERQ> <GETMIMERS> 749.3.2 Example 759.4 E-Mail Message Set Profile Information 7610. Recurring Transactions 7710.1 Creating a Recurring Model 7710.2 Recurring Instructions <RECURRINST> 7710.2.1 Values for <FREQ> 7810.2.2 Examples 7910.3 Retrieving Transactions Generated by a Recurring Model 8010.4 Modifying and Canceling Individual Transactions 8010.5 Modifying and Canceling Recurring Models 8010.5.1 Examples 81 <ol> <li><a NAME="_Toc380493239">Overview</a> </li> <li><a NAME="_Toc380493240">Introduction</a> </li> </ol> Open Financial Exchange is a broad-based framework for exchanging financial data and instructions between customers and their financial institutions. It allows institutions to connect directly to their customers without requiring an intermediary. Open Financial Exchange is an open specification that anyone can implement: any financial institution, transaction processor, software developer or other party. It uses widely accepted open standards for data formatting (such as SGML), connectivity (such as TCP/IP and HTTP), and security (such as SSL). Open Financial Exchange defines the request and response messages used by each financial service as well as the common framework and infrastructure to support the communication of those messages. This specification does not describe any specific product implementation. <ol> <li><a NAME="_Toc380493241">Design Principles</a> </li> </ol> The following principles were used in designing Open Financial Exchange: l Broad Range of Financial Activities - Open Financial Exchange provides support for a broad range of financial activities. Open Financial Exchange 1.0 specifies the following services: n Bank statement download n Credit card statement download n Funds transfers including recurring transfers n Consumer payments, including recurring payments n Business payments, including recurring payments n Brokerage and mutual fund statement download, including transaction history, current holdings and balances l Broad Range of Financial Institutions - Open Financial Exchange supports communication with a broad range of financial institutions (FIs), including: n Banks n Brokerage houses n Merchants n Processors n Financial advisors n Government agencies l Broad Range of Front-End applications - Open Financial Exchange supports a broad range of front-end applications covering all types of financial activities running on all types of platforms, including Web-based applications. l Extensible - Open Financial Exchange has been designed to allow the easy addition of new services. Future versions will include support for many new services. l Open - This specification is publicly available. You can build client and server applications using the Open Financial Exchange protocols independent of any specific technology, product, or company. l Multiple Client Support - Open Financial Exchange allows a user to use multiple client applications to access the same data at a financial institution. With the popularity of the World Wide Web, customers are increasingly more likely to use multiple applications-either desktop-based or Web-based-to perform financial activities. For example, a customer can track personal finances at home with a desktop application and occasionally pay bills while at work with a Web-based application. The use of data synchronization to support multiple clients is a key innovation in Open Financial Exchange. l Robust - Open Financial Exchange will be used for executing important financial transactions and for communicating important financial information. Assuring users that transactions are executed and information is correct is crucial. Open Financial Exchange provides robust protocols for error recovery. l Secure - Open Financial Exchange provides a framework for building secure online financial services. In Open Financial Exchange, security encompasses authentication of the parties involved, as well as secrecy and integrity of the information being exchanged. l Batch & Interactive - The design of request and response messages in Open Financial Exchange is for use in either batch or interactive style of communication. Open Financial Exchange provides for applying a single authentication context to multiple requests in order to reduce the overhead of user authentication. l International Support - Open Financial Exchange is designed to supply financial services throughout the world. It supports multiple currencies, country-specific extensions, and different forms of encoding such as UNICODE. l Platform Independent -Open Financial Exchange can be implemented on a wide variety of front-end client devices, including those running Windows 3.1, Windows 95, Windows NT, Macintosh, or UNIX. It also supports a wide variety of Web-based environments, including those using HTML, Java, JavaScript, or ActiveX. Similarly on the back-end, Open Financial Exchange can be implemented on a wide variety of server systems, including those running UNIX, Windows NT, or OS/2. l Transport Independent - Open Financial Exchange is independent of the data communication protocol used to transport the messages between the client and server computers. Open Financial Exchange 1.0 will use HTTP. <ol> <li><a NAME="_Toc380493242">Open Financial Exchange </a>at a Glance </li> </ol> The design of Open Financial Exchange is as a client and server system. An end-user uses a client application to communicate with a server at a financial institution. The form of communication is requests from the client to the server and responses from the server back to the client. Open Financial Exchange uses the Internet Protocol (IP) suite to provide the communication channel between a client and a server. IP protocols are the foundation of the public Internet and a private network can also use them. <ol> <li><a NAME="_Toc380493243">Data Transport</a> </li> </ol> Clients use the HyperText Transport Protocol (HTTP) to communicate to an Open Financial Exchange server. The World Wide Web throughout uses the same HTTP protocol. In principle, a financial institution can use any off-the-shelf web server to implement its support for Open Financial Exchange. To communicate by means of Open Financial Exchange over the Internet, the client must establish an Internet connection. This connection can be a dial-up Point-to-Point Protocol (PPP) connection to an Internet Service Provider (ISP) or a connection over a local area network that has a gateway to the Internet. Clients use the HTTP POST command to send a request to the previously acquired Uniform Resource Locator (URL) for the desired financial institution. The URL presumably identifies a Common Gateway Interface (CGI) or other process on an FI server that can accept Open Financial Exchange requests and produce a response. The POST identifies the data as being of type application/x-ofx. Use application/x-ofx as the return type as well. Fill in other fields per the HTTP 1.0 spec. Here is a typical request: <pre> POST http://www.fi.com/ofx.cgi HTTP/1.0 User-Agent:MyApp 5.0 Content-Type: application/x-ofx Content-Length: 1032 OFXHEADER:100 DATA:OFXSGML VERSION:100 SECURITY:1 ENCODING:USASCII <OFX> ... Open Financial Exchange requests ... </OFX> </pre> A blank line defines the separation between the HTTP headers and the start of the actual Open Financial Exchange data. A blank line also separates the Open Financial Exchange headers and the actual response. (See Chapter 2, for more information.) The structure of a response is similar to the request, with the first line containing the standard HTTP result, as shown next. The content length is given in bytes. <pre> HTTP 1.0 200 OK Content-Type: application/x-ofx Content-Length: 8732 OFXHEADER:100 DATA:OFXSGML VERSION:100 SECURITY:1 ENCODING:USASCII <OFX> ... Open Financial Exchange responses ... </OFX> </pre> <ol> <li><a NAME="_Toc380493244">Request and Response</a> Model </li> </ol> The basis for Open Financial Exchange is the request and response model. One or more requests can be batched in a single file. This file typically includes a signon request and one or more service-specific requests. An FI server will process all of the requests and return a single response file. This batch model lends itself to Internet transport as well as other off-line transports. Both requests and responses are plain text files, formatted using a grammar based on Standard Generalized Markup Language (SGML). Open Financial Exchange is syntactically similar to HyperText Markup Language (HTML), featuring tags to identify and delimit the data. The use of a tagged data format allows Open Financial Exchange to evolve over time while continuing to support older clients and servers. Here is a simplified example of an Open Financial Exchange request file. (This example does not show the Open Financial Exchange headers and the indentation is only for readability.) For complete details, see the more complete examples throughout this specification. <OFX>  <SIGNONMSGSRQV1> <SONRQ>  <DTCLIENT>19961029101000  <USERID>123-45-6789  <USERPASS>MyPassword  <LANGUAGE>ENG  <FI>  <ORG>NCH  <FID>1001  </FI> <APPID>MyApp <APPVER>0500 </SONRQ>  </SIGNONMSGSRQV1> <BANKMSGSRQV1> <STMTTRNRQ>  <TRNUID>1001 <STMTRQ>  <BANKACCTFROM>  <BANKID>121099999  <ACCTID>999988  <ACCTTYPE>CHECKING  </BANKACCTFROM>  <INCTRAN>  <INCLUDE>Y  </INCTRAN>  </STMTRQ>  </STMTTRNRQ>  </BANKMSGSRQV1></OFX> The response format follows a similar structure. Although a response such as a statement response contains all of the details of each transaction, each element is identified using tags. The key rule of Open Financial Exchange syntax is that each tag is either an element or an aggregate. Data follows its element tag. An aggregate tag begins a compound tag sequence, which must end with a matching tag; for example, <AGGREGATE> ... </AGGREGATE>. The actual file Open Financial Exchange sends is without any extra white space between tags. <ol> <li><a NAME="_Toc380493245">Conventions</a> </li> </ol> The conventions used in the detailed descriptions include: <ul> <li>Required tags are in bold. Regular face indicates tags that are optional. Required means that a client will always include a tag in a request, and a server must always include a tag in a response. </li> <li>Italic shows a required or optional aggregate from a set of possible aggregates. </li> <li>Required tags occur once unless noted as one or more in the description, in which case the specification allows multiple occurrences. </li> <li>Optional tags occur once if present unless noted as zero or more in the description, in which case the specification allows multiple occurrences. </li> <li>Allowable specific values are listed, where applicable. </li> <li>A-n or N-n, specify those values that take general alphanumeric or pure numeric type values, where n indicates the maximum size. </li> <li>References to certain common value types, such as a dollar amount, are by name. Chapter 3 lists value types that can be referenced by name. </li> </ul> <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="162">Tag </td> <td BGCOLOR="#000000" WIDTH="336">Description </td> </tr> <tr> <td WIDTH="162"><REQUIREDTAG> </td> <td WIDTH="336">Required tag (1 or more) </td> </tr> <tr> <td WIDTH="162"><REQUIREDTAG2> </td> <td WIDTH="336">Required tag that occurs only once </td> </tr> <tr> <td WIDTH="162"><OPTIONALTAG> </td> <td WIDTH="336">Optional tag; this particular one can occur multiple times (0 or more) </td> </tr> <tr> <td WIDTH="162"><SPECIFIC></td> <td WIDTH="336">Values are A, B, and C </td> </tr> <tr> <td WIDTH="162"><ALPHAVALUE></td> <td WIDTH="336">Takes an alphanumeric value up to 32 characters, A-32 </td> </tr> </table> <ol> <li><a NAME="_Toc380493246">Structure</a> </li> </ol> This chapter describes the basic structure of an Open Financial Exchange request and response. Structure includes headers, basic syntax, and the Signon request and response. This chapter also describes how Open Financial Exchange encodes external data, such as bit maps. Open Financial Exchange data consists of some headers plus one or more Open Financial Exchange data blocks. Each block consists of a signon message and zero or more additional messages. When sent over the internet using HTTP, standard HTTP and multi-part MIME headers and formats surround the Open Financial Exchange data. A simple file that contained only Open Financial Exchange data would have the following form: <pre> HTTP headers MIME type application/x-ofx Open Financial Exchange headers Open Financial Exchange SGML block 1 </pre> A more complex file that contained multiple Open Financial Exchange data blocks and additional Open Financial Exchange data would have this form: <pre> HTTP headers MIME type multipart/x-mixed-replace; boundary =--boundary- ---boundary--- MIME type application/x-ofx Open Financial Exchange headers Open Financial Exchange SGML block 1 Open Financial Exchange SGML block 2 ---boundary--- MIME type image/jpeg FI logo </pre> <ol> <li><a NAME="_Toc380493247">HTTP Headers</a> </li> </ol> Data delivered by way of HTTP places the standard HTTP result code on the first line. HTTP defines a number of status codes. Servers can return any standard HTTP result. However, FIs should expect clients to collapse these codes into the following three cases: <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="84">Code </td> <td BGCOLOR="#000000" WIDTH="96">Meaning </td> <td BGCOLOR="#000000" WIDTH="312">Action </td> </tr> <tr> <td WIDTH="84">200</td> <td WIDTH="96">OK </td> <td WIDTH="312">The request was processed and a valid Open Financial Exchange result is returned. </td> </tr> <tr> <td WIDTH="84">400s</td> <td WIDTH="96">Bad request </td> <td WIDTH="312">The request was invalid and was not processed. Clients will report an internal error to the user. </td> </tr> <tr> <td WIDTH="84">500s</td> <td WIDTH="96">Server error </td> <td WIDTH="312">The server is unavailable. Clients should advise the user to retry shortly. </td> </tr> </table> NOTE: Open Financial Exchange returns a code 400 only if it cannot parse the file. Open Financial Exchange handles content errors such as wrong PIN, or invalid account, by returning a valid Open Financial Exchange response along with code 200. Open Financial Exchange requires the following HTTP standard headers: <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="84">Code </td> <td BGCOLOR="#000000" WIDTH="96">Value </td> <td BGCOLOR="#000000" WIDTH="312">Explanation </td> </tr> <tr> <td WIDTH="84">Content-type</td> <td WIDTH="96">application/x-ofx </td> <td WIDTH="312">The MIME type for Open Financial Exchange </td> </tr> <tr> <td WIDTH="84">Content-length</td> <td WIDTH="96">length </td> <td WIDTH="312">Length of the data after removing HTTP headers </td> </tr> </table> <pre> </pre> When responding with multi-part MIME, the main type will be multi-part/x-mixed-replace; one of the parts will use application/x-ofx. <ol> <li><a NAME="_Toc380493248">Open Financial Exchange Headers</a> </li> </ol> The intent of Open Financial Exchange is for use with a variety of transports and to provide sufficient version control capabilities for future expansion. To support this goal, the contents of an Open Financial Exchange file consist of a simple set of headers followed by contents defined by that header. "File format" means the entire content after removal of any transport headers. The HTTP transport described in this document, means without the HTTP and MIME headers. The Open Financial Exchange headers are in a simple tag:value syntax and terminated by a blank line. Open Financial Exchange always sends headers unencrypted, even if there is application-level encryption in use for the remaining contents. The first entry will always be OFXHEADER with a version number. This entry will help identify the contents as an Open Financial Exchange file, and provides the version of the Open Financial Exchange headers that follow (not of the content itself). For example: <pre> OFXHEADER:100 </pre> This document defines version 1.0 of the headers to contain at least the following additional tags: <pre> DATA:OFXSGML VERSION:100 SECURITY: ENCODING: CHARSET: COMPRESSION: OLDFILEUID: NEWFILEUID: </pre> The data tag identifies the contents as being in OFX SGML form. VERSION identifies the version type as OFXSGML data. In the case of OFXSGML, it translates to the version of the Document Type Definition (DTD) that it uses for parsing. The ENCODING and CHARSET tags define the interpretation of the character data. See Chapter 5, "International Support" for more information on these tags. Chapter 4 describes the security tag. A future version of this specification will define compression. Open Financial Exchange uses OLDFILEUID and NEWFILEUID to support error recovery. They are not present when clients are not requesting error recovery. (See Chapter 6, "Data Synchronization") A blank line follows the last tag. Then (for type OFXSGML), the SGML-readable data begins with the <OFX> tag. NOTE: Here, VERSION provides the overall version of the DTD. The <OFX> block describes the specific message set versions used, shown later in this chapter. <ol> <li><a NAME="_Toc380493249">The Meaning of Version Numbers</a> </li> </ol> The OFXHEADER value should only change its major number if an existing client is unable to process the new header. This can occur because of a complete syntax change in a header, or a significant change in the semantics of an existing tag-not the entire response. You can add new tags as long as clients can function without understanding them. You should add new values for a data tag only when you introduce an entirely new syntax. In the case of OFXSGML, a new syntax would have to be non-SGML compliant to warrant a new data value. It is possible that there will be more than one syntax in use at the same time to meet different needs. The intent of the header version tag is to identify syntactic changes. In the case of OFXSGML, this corresponds to the DTD. Purely for identification purposes, each change will increment the minor number of the version tag. If you introduce an incompatible change so that an older DTD can not parse the file, the major number will change. See the general discussion of message sets and version control, later in this chapter. <ol> <li><a NAME="_Toc380493250">SGML Details</a> </li> <li><a NAME="_Toc380493251">Compliance</a> </li> </ol> SGML is the basis for Open Financial Exchange. There is a DTD that formally defines the SGML wire format. However, Open Financial Exchange is not completely SGML-compliant because the specification allows unrecognized tags to be present. It requires clients and servers to skip over the unrecognized material. That is, if <XYZ>qqq</XYZ> appeared and a client or server cannot recognize <XYZ>, the server should ignore that tag and its enclosed data. A fully-compliant SGML parser would not validate an Open Financial Exchange document if it contained any tags that the DTD does not define. Although SGML is the basis for the specification, and the specification is largely compliant with SGML, do not assume Open Financial Exchange supports any SGML features not documented in this specification. The intent is to allow parsing to be as simple as possible, while retaining compatibility with the SGML world. <ol> <li><a NAME="_Toc380493252">Special Characters</a> </li> </ol> The following characters are special to SGML. Use the given alternative sequence to represent them: <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="162">Character </td> <td BGCOLOR="#000000" WIDTH="336">Escape sequence </td> </tr> <tr> <td WIDTH="162">< (less than)</td> <td WIDTH="336">&lt; </td> </tr> <tr> <td WIDTH="162">> (greater than)</td> <td WIDTH="336">&gt;</td> </tr> <tr> <td WIDTH="162">& (ampersand)</td> <td WIDTH="336">&amp; </td> </tr> </table> For example, the string "AT&amp;T" encodes "AT&T." A special case applies in specific tags that can accept HTML-formatted strings, such as e-mail records. These accept SGML marked section syntax to hide the HTML from the Open Financial Exchange parser. You must prefix strings with "<![ CDATA ["and suffixed with"]]>." Within these bounds, treat the above characters literally without an escape. See the Chapter 9 for an example. <ol> <li><a NAME="_Toc380493253">Open Financial Exchange SGML Structure</a> </li> <li><a NAME="_Toc380493254">Overview</a> </li> </ol> Open Financial Exchange hierarchically organizes request and response blocks: Top Level <OFX> Message Set and Version <XXXMSGSVn> Synchronization Wrappers <YYYSYNCRQ>, <YYYSYNCRS> Transaction Wrappers <YYYTRNRQ>, <YYYTRNRS> Specific requests and responses The following sections describe each of these levels. <ol> <li><a NAME="_Toc380493255">Top Level</a> </li> </ol> An Open Financial Exchange request or response has the following top-level form: <table BORDER="1"> <tr> <td BGCOLOR="#000000" WIDTH="162">Tag </td> <td BGCOLOR="#000000" WIDTH="336">Description </td> </tr> <tr> <td WIDTH="162"><OFX></td> <td WIDTH="336">Opening tag</td> </tr> <tr> <td WIDTH="162">... Open Financial Exchange requests or responses ... </td> <td WIDTH="336">0 or more transaction requests and responses inside appropriate message set aggregates </td> </tr> <tr> <td WIDTH="162"></OFX></td> <td WIDTH="336">Closing tag for the Open Financial Exchange record </td> </tr> </table> This chapter specifies the order of requests and responses. A single file can contain multiple <OFX> ... </OFX> blocks. A typical use of multiple blocks is to request in a single file information associated with different users. <ol> <li><a NAME="_Toc380493256">Messages</a> </li> </ol> A message is the unit of work in Open Financial Exchange. It refers to a request and response pair, and the status codes associated with that response. For example, the message to download a bank statement consists of the request <STMTRQ> and the response <STMTRS>. In addition, with the exception of the signon message, each message includes a transaction wrapper. These aggregates add a transaction unique ID <TRNUID>, and for responses, a <STATUS> aggregate, to the basic request and response. For messages subject to synchronization (see Chapter 6), a third layer of aggregates is also part of a message definition: a synchronization request and response. These add a token and, in some cases, other information to the transactions. Open Financial Exchange uses the following naming where the XXX message includes: <ul> <li>Basic request <XXXRQ> and response <XXXRS> </li> <li>Transaction wrapper <XXXTRNRQ> and <XXXTRNRS> </li> <li>If needed, synchronization wrapper <XXXSYNCRQ> and <XXXSYNCRS> </li> </ul> In a few cases, a small number of related basic requests and responses share a transaction and synchronization wrapper. The term message will still apply to each request and response; only the naming scheme will not hold in those cases. <ol> <li><a NAME="_Toc380493257">Message Sets and Version Control</a> </li> </ol> Message sets are collections of messages. Generally they form all or part of what a user would consider a service, something for which they might have signed up, such as "banking." Message sets are the basis of version control, routing, and security. They are also the basis for the required ordering in Open Financial Exchange files. Within an Open Financial Exchange block, Open Financial Exchange organizes messages by message set. A message set can appear at most once within an Open Financial Exchange block. All messages from a message set must be from the same version of that message set. For each message set of XXX and version n, there exists an aggregate named <XXXMSGSVn>. (Compare with <XXXMSGSETVn> in Chapter 7.) All of the messages from that message set must be inside the appropriate message set aggregate. In the following example, the Open Financial Exchange block contains a signon request inside the signon message set, and two statement requests and a transfer request inside the bank message set. </body> </html> `; const pattern = /<body[^>]*>((.|[\n\r])*)<\/body>/im; const matches = pattern.exec(html); const body = matches[1]

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Dom Parser
Regex

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 2 years ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Browser/OS: Chrome 120 on Windows

View result in a separate tab

Test name	Executions per second
Dom Parser	2605.8 Ops/sec
Regex	16833.4 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Related benchmarks:

test DomParser with medium HTML string (version: 0)

Comparing performance of: Dom Parser vs Regex

Created: 2 years ago by: Guest

Jump to the latest result

Dom Parser

Regex

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):