Abstract: This paper presents an XML-based mobile terminal web browsing solution that inserts a middleware layer into the traditional client/server browsing model. The middleware layer runs on a backend server, receives client service requests, communicates with the web server to obtain the required HTML files, filters these files according to specifications, reorganizes them into XML format, and transmits them to the client via a wireless network. The client platform uses embedded Linux, which can be customized as needed. After XML parsing, it calls GUI functions to display the webpage. Keywords: Embedded browser, mobile terminal, XML parser I. Introduction Mobile terminals are constrained by mobility and portability, resulting in smaller CPU clock speeds and computing power, as well as limitations on memory capacity, display screen size, and input device size. Simultaneously, wireless data networks have relatively low bandwidth, connection reliability, and network predictability, with higher latency than wired networks. Directly connecting mobile terminals to the Internet wirelessly presents technical challenges. In recent years, the industry has proposed two approaches: First, rewriting existing Internet protocols to ensure compatibility, allowing mobile devices to access WAP-specific information and services via wireless networks through micro-browsers. Another approach is to treat mobile terminals as simplified PCs with built-in HTML browsers. While this allows free access to existing networks, the extensive use of Flash and Shockwave technologies in existing Internet websites results in large file sizes, long transmission times over wireless distances, and requires significant computing power from the mobile terminal, leading to high hardware investment. Therefore, this approach is improved to meet the requirement of small data volumes in wireless network transmission while still allowing users to access most resources on the existing network. II. XML-Based Mobile Terminal Web Browsing Model 1. Model Overview The XML-based web browsing solution inserts a middleware layer into the traditional client/server browsing model. The middleware layer receives service requests from the client, communicates with the web server to obtain the necessary HTML files, filters these files according to certain specifications, removes unnecessary tags and content, and reorganizes them into XML format files for transmission to the client via the wireless network. After passing through the XML parser, GUI graphical interface functions are called to display the webpage on the user interface. The client browser's control section is responsible for responding to user requests and handling user interactions. Its structure is shown in Figure 1. 2. Advantages and Disadvantages of Using XML in Wireless Network Browsing. Extensible Markup Language (XML) is a meta-language used to describe other languages, defining the structure of data transfer between applications. It is text that can be read by any editor. Using this mechanism, programmers can define the underlying data exchange specifications and develop various modules of the entire system on this basis. Data that conforms to established rules is transferred between modules, making it suitable for transferring structured data between computers. The built-in document parser in each browser is one of the most crucial parts, affecting the browser's operating efficiency and space efficiency. Because XML uniformly defines the standard interface specification for its document parser—DOM (Document Object Model)—applications can choose and replace appropriate parsers as needed without making major modifications to the program itself. In the browsing model, computationally intensive tasks such as HTML parsing are handled by the middle-tier server, while the client performs relatively simple XML parsing, conforming to the thin client/server information application architecture model. Currently, the biggest problem with using XML is the limited number of applications that support it; many specific applications still require developers to design them themselves. 3. Mechanism and principle of middle layer implementation VC++ 6.0 is selected as the integrated development environment for middle layer. Middle layer runs on backend server and adopts modular design. Each module is a regular dynamic link library (Regular DLL) unit, which is dynamically loaded by backend server when needed. (1) Several wireless MODEMs are connected to the backend server through multi-serial port cards to form a wireless MODEM pool to provide services to multiple mobile terminal users. When the client establishes a connection with the server, it first applies for idle resources in the MODEM pool and establishes a connection with the backend server, sends a client browser service request, and releases MODEM resources after the task is completed. If there are no available resources, it waits for a certain period of time and then applies again. (2) The backend server accesses the Internet through wired network and uses standard WWW protocol stack (HTTP, TCP/IP, etc.). When communicating with WEB server, it mainly uses three MFC classes: CInternetSession, CHttpConnection and ChttpFile. The core code is as follows: CI Internet Session session; CHttp Connection * p Server = NULL; CHttp File * p File = NULL; AfxParseURL(pURL,…); After initialization, the client's service request is converted into a standard Uniform Resource Locator (URL), and the global function AfxParseURL is called to analyze and map this URL. pServer = session.GetHttpConnection(); pFile = pServer->OpenRequest(); pFile->AddRequestHeaders(); pFile->SendRequest(); Open the client request for a specific HTTP connection and send the corresponding HTTP request message to the WEB server. pFile->ReadString(); The WEB server returns a response message, and the ReadString function of the CHttpFile class is called to obtain the returned data, completing the communication with the WEB server. (3) The parsing engine in the Dillo project browser is selected as the core of the parsing, filtering and assembly module. The process is shown in Figure 2. The HTML parsing section breaks down the input HTML data stream character by character into three categories according to HTML syntax characteristics: ① Space data type: All characters with ASCII code values ​​between 0x09 and 0x0d or 0x20 represent spaces or placeholder information. This data is processed by the Space_proces section to determine its length. To maintain the basic HTML formatting, this type of data is stored entirely in the generated XML file. ② Tag data type: Represents all tags in the HTML data stream. Due to the limitations of HTML syntax rules, the validity of tags must be checked, for example... The label must exist

Within the tags. A stack is created to store tag information; all elements in the stack constitute the current state information of the HTML text. When a new tag is encountered, it is first compared with the current state information according to HTML syntax rules. If valid, the current tag information (including tag name and attributes) is pushed onto the stack, and popped from the stack at the end of the tag. This process is handled by the `Tag_process` part. Simultaneously, an array is created to store the tag names to be retained; the specific elements in the array can be added or removed as needed by the user. Each valid tag is compared one by one with the elements in the array to determine whether the tag should be added to the XML file. This filtering reduces the amount of wireless transmission. ③ Word data type: The text information to be displayed. This information is processed by `Word_process` and then added to the XML file. ④ Finally, the XML file is transmitted to the client browser via the wireless network. Due to the uncertainty and instability of data transmission in wireless communication environments, an HTML conversion module communication submodule – PDA – is defined: Protocol format: FramHead (0x01) + ASCII data length (6 bytes) + instruction + space + ASICII data + FramTail (0x02) 4. Supported instructions OK FAIL. The first field represents the data frame header, the second field represents the total data length in decimal, with a maximum of 999999 bytes, the instruction field indicates the working status of the intermediate layer server, returning OK if successful, and finally the frame trailer. The integrity and accuracy of data transmission are determined by checking the frame header and frame trailer. Testing shows that after filtering out JavaScript and some dynamic images through the intermediate layer while retaining the main information of the webpage, the webpage size is only about 10% of the original, making it suitable for transmission on low-speed wireless networks such as GSM. III. Implementation Mechanism of Client Browser The client platform adopts embedded Linux. The workflow is as follows: (1) After the browser starts, it first initializes the XmlBrowser structure. This structure includes the browser's current URL, the display structure entry pointer, and the member structure that saves the historical URLs that have been browsed. After initialization, it sends a request message to the middle layer through the client communication module. Its communication submodule, the middle layer server communication submodule, has the following format: Protocol format FramHead (0x01) Total length (4 bytes) Instruction space URL string? [POST DATA] FramTail (0x02) Supported instructions GET POST HEAD The first two fields represent the frame header and data length respectively. The last four fields follow the HTTP protocol and support the three standard HTTP instructions. The last one is the frame tail. (2) After receiving the data returned by the intermediate layer, the browser first checks that no data is lost during the data transmission and then sends this XML data stream to the XML parser. It selects the XML parser in the XML Library, which provides XML support as one of the main window management environments of Gnome Linux. It follows the standard DOM interface and can be regarded as a standard structural system for connecting documents and application or scripting languages. It provides users with an interface to load positioning operations and serialize XML documents. The DOM-based XML parser converts the XML document into a collection of object models, usually in a tree structure. By traversing the entire tree, the content and structural information of any part of the XML document can be accessed. (3) The steps from XML parsing to XML text display are shown in the flowchart Figure 3. It can be seen that the underlying GUI interface call and the upper display module are separate. After the display module completes the calculation of the display information of all specific elements, it sends a service request to the underlying GUI interface function. The underlying GUI responds to the service request and completes the screen drawing. With this structure, the application developer does not need to understand the implementation mechanism and technical details of the underlying graphics engine. As long as the interface between the two remains unchanged, the upgrade of the system's underlying graphics function library will not affect the existing software. The elements entering the displayed DOM data stream fall into two categories: one is objects displayed on the screen display area, such as input boxes. Links and text elements are alternative containers, such as table rows. Table cell Elements are not displayed on the screen. Each display object is located in a specific container to determine its relative position to other display objects. The entire screen display area is regarded as the outermost container, which contains the actual display object and the lower container. This is how the entire display structure is formed. After the display structure is completed, the actual display position of each element is calculated. By traversing the entire display structure, the coordinates of each display object are calculated based on the length and width of the display area. The parts that exceed the length of the display area are accessed using the scroll bar. (4) Management of browser and user interaction This management is completed by the browser's virtual controller. In addition to the page display area, the browser's entire screen is divided into the scroll bar and the system area. The system area provides users with some customized functions, such as forward, backward, and page refresh. By clicking the scroll bar area, the screen can be moved up and down. IV. Conclusion The XML-based mobile terminal web browsing solution takes into account the current situation where the network data structure is mainly HTML and can meet the future trend of the network developing towards XML. It has been successfully run on the mobile terminal developed by our institute and meets the needs of highly mobile special industries for information browsing and querying.