A New Paradigm of Parsing XML based on Free Cursor Mobility (FCM):

Antonio J. Sierra
antonio@trajano.us.es

Abstract

An XML parser is a program that facilitates manipulating XML data. Event-based paradigms read the information pointed at by the cursor in the XML data to generate different events depending on the information read, but do not manage information previously read. I present a new event-based paradigm to parse XML documents, based on free cursor mobility (FCM). FCM allows the posibility of moving the cursor back to previously read information. This model gives parsing control to the programmer by exposing a simple iterator-based API and an underlying stream of events.

Keywords: Parsing; DOM

Antonio J. Sierra

Antonio J. Sierra Collado received the Telecommunications Engineering degree from the Polytechnic University of Catalonia, Barcelona, Spain in 1995, and completed the Ph. D. Proposal from the Polytechnic University of Catalonia, Barcelona in 1998. He has collaborated in projects and training courses for several companies. He has also participated in other research projects. Since 1996 he is an Assistant-Professor at the University of Sevilla. His main research interests include development of XML, Java, Web Services and Grid Services applications.

A New Paradigm of Parsing XML based on Free Cursor Mobility (FCM)

Antonio J. Sierra [Assistant Professor; University of Sevilla, Escuela Superior de Ingenieros, Departament of Sistemas and Automatic, Area of Engineering Telematic]

Extreme Markup Languages 2005® (Montréal, Québec)

Copyright © 2005 Antonio J. Sierra. Reproduced with permission.

Outlines

The emergence of a diversity of competing and complementary XML[Bray 04] application technologies is driving the XML industry to broaden their standards and applications in environments such as resource-constrained devices as platforms with limited memory. Human readably of XML documents imposes a high cost for platforms with limited memory. This property presents a new challenge, requiring new solutions.

Existing XML parsing models can be too heavy for certain platforms with resource-constrained devices, such as mobile phones based on CLDC[CLDC]. A parsing paradigm sets the criteria and performace, and the way in which any application can access information contained in the XML data. Tree-based paradigms are considered too memory intensive for CLDC devices. Event-based paradigms read the information pointed at by the cursor in the XML to generate different events depending on the information read, but do not manage information previously read.

This paper presents a new event-based paradigm to parse XML documents, based on free cursor mobility (FCM). FCM allows the posibility of moving the cursor back to previously read information. This model gives parsing control to the programmer by exposing a simple iterator-based API and an underlying stream of events. This allows the programmer to stop processing the document, skip ahead and back to sections of the documents, and retrieve subsections using references to the stored information.

This paper addresses the following questions:

  • Shows which paradigms are used in the XML parser and their characteristics, advantages, drawbacks or limitations.
  • Shows the new model.
  • Presents an implementation using the Java programming language for the J2ME [J2ME] and the model's validation.

The document is organized as follows: First I present the motivation for the new model. Next, I present the state of the art of model parsing, followed by the new proposal in which I present a new parsing model. Next, I illustrate a Java implementation for J2ME. Then, I validate the proposal relating it to the other parsers for the same platform. And finally, I present conclusions.

Motivation

In recent years, the Extensible Markup Language (XML) has been adopted by more and more businesses as an industry standard for data exchange and data sharing that provides a system-independent standard format for specifying the information exchanged over networks and between applications. Most of them are executed over Java's platform. Java and XML are a excellent combination, Java is portable code and XML is portable data. Developing in Java gives the ability to deploy code on many different platforms, while XML supplies a highly portable data format for exchanging data between application componetes and applications themselves. Application Programming Interfaces (API) provides a point to acces implementation specifying methods's name, parameter and return value, without know how applications has been implemented.

XML parsing creates such extra load for CPU, memory and network bandwidth that traditional application running on desktops and servers that may not be good solutions, for transmitting, storing, and parsing XML data. It is very important to have an efficient way to parse XML data, especially in applications that are intended to handle large volumes or small platform.

With DOM [DOM], the parser creates an internal model of a document as it is parsed, and after parsing is complete, an application can examine the entire document. Parsers that implement event-based models, in general, are faster and consume less CPU and memory than parsers for model-based models.

Parsers in constrained-resource platforms usually support a strict subset of functionality available for the other platform. The size of the application must be smaller those on platforms without memory restrictions. J2ME Web Services (JSR-172) [JSR-172] does not provide any support for the Document Object Model (DOM). The DOM is generally considered to be too heavy, both in terms of implementation size and runtime memory footprint to be used on the J2ME platform. Tree-based XML parser is easier to access and manipulate, but is memory intensive. Event-based XML parser are small memory footprint and fast execution speeds, but limited by only supporting serial access to data without movement back to previously read information.

This paper presents a new event-based technique for parsing XML which, provides serial-access mechanism for accessing XML data, where we can go back to an earlier position or leap ahead to a different position. FCM maintain the iterative pattern that involves pull. A FCM's implementation need to mantain a serialized representation (that could be the virtual data source) to move back the cursor. The new model can be considered as an evolution of pull model. An implementation has been realized from StAX [JSR-173] Section 4.12, providing the new model's capabilities.

State of the Art

In this section, I show the state of the art of XML document parsing models. Then, I present the advantages and drawbacks for the different XML parsing models.

Introduction

An XML file is some collection of data that is demarcated by tags. An XML document is a tagged data file based on structure and meaning, that must be parsed to retrieve the data.

The parser manipulates XML data extracted from an XML data source, such as a file. These data can be used as a serialized representation for managing it internally.

A parser provides XML information obtained from the serialized representation, to application through API's methods. There are three models or paradigms:

  • Document Object Model
  • Push
  • Pull

Document Object Model

DOM is an industry standard tree-based interface for XML parsing, and is the official W3C standard for representing XML documents in a platfom- and language-neutral manner. It serves as a good basis for comparison for Java-specific models that offer significant performance and/or ease-of-use advantages. With Document Object Model (DOM), the parser creates an internal model of a document as it its parsed. After parsing is complete, an application can examine the entire document.

The name "Document Object Model" was chosen because it is an "object model" in the traditional object oriented design. The model encompasses not only the structure of a document, but also its behavior and that of the objects of which it is composed. In other words, the nodes in the diagram below do not represent a data structure, rather they represent objects which have functions and identity.

Figure 1: Document Object Model.
[Link to open this graphic in a separate page]

DOM provides APIs that allow access and manipulation of an in-memory XML document. At first glance this seems like an advantage for the application developer. However, this perceived simplicity comes at very high cost, that is, performance. For very large documents one may be required to read the entire document into memory before taking appropriate actions based on the data. Although none of the parsers at J2ME implement DOM directly, some of them do follow the DOM paradigm of creating an internal representation of a parsed document.

Push

Push is an event-driven system whose only API implementation is the Simple API for XML (SAX)[Megginson]. SAX is a standard event-based interface for XML parsing that implements an event-based push model.

Event-based XML parsers read the information pointed to by the cursor in the XML data parsing to generate different events depending on the information read. An event is produced when in the process of reading information from an XML has particular relevance or significance to be considered for the parser. This event is notified to the application.

An even-based XML push parser reports parsing events directly to the applications through callback methods. Applications that use this parser need to implement callback methods to receive parsing events from the parser (i.e., the startElement()). In callback methods the control is not in the hands of the application, rather in those of the parser. The parser notifies the aplication each time it parses a section of an XML document; and the applications can respond, in the moment in which it is generated, to this event and give or store the information avalaible to this event.

Push provides a serial-access mechanism for accessing XML data. These low-level events can be used by the application to build its own in-memory representation of the XML document, with implementation of the interface's event-handlers to receive parsing events.

Figure 2: Producer and Consumer to Push Model.
[Link to open this graphic in a separate page]

In SAX the typical communication pattern is from producer to consumer. The first role is an event producer, which is typically an XML parser. The producer is in charge of pushing parsing events to objects that serve the second role, event consumer.

Pull

Pull[Pull] is an event-driven system where the application explicitly calls the parser to obtain the next parsing event, in an iterative process. The loop is a very common pattern in this model.

Streaming API for XML[JSR-173] is a Java XML pull parsing API. The application in this model will repeatedly call next() method to retrieve next event. The iterative process has been associated with the Java the Iterator, using the same methods, hasNext() and next(), in order to know if there are more events and to take in the events, respectively.

Figure 3: Producer and Consumer to Pull Model.
[Link to open this graphic in a separate page]

A Java Iterator permits movement through a sequence of objects and the selection of each one from the sequence. Iteration has been asociated to the pull model. This process permits an application developer to ask for the next event (pull the event) rather than handling the event in a callback. This performance gives more procedural control over the processing to the developer, allowing it to stop processing the document.

Pull is a fast, potentially extremely fast, straight-forward, memory-thrifty way to parse XML data.

A limitation with these event-based systems is that parsers can't access XML data previously processed. FCM offers an improvement of the event-based model. The application can skip ahead and go back to sections of the document, and retrieve subsections of the document using references to the stored information without loading the document in memory, and facilitating efficient movement through the XML document.

The New Paradigm

This section presents a new event-driven system to parse XML data based on the free cursor mobility (FCM). First, we present the model FCM's producer/consumer. Then, I present the new operations for the new model. And finally, an example of use is presented.

Introduction

FCM is an new event-driven model that extends the pull model which, provides serial-access mechanism for accessing XML data, to append back cursor mobility. In this model the cursor can go back to an earlier position or leap ahead to a different position.

FCM maintain the iterative pattern that involves pull parsing. FCM gives parsing control to the programmer by providing the simple iterator-based API of pull model, and can go back to sections read of XML, for generating underlying stream of events. The new event-driven parsing can be used to trim and recreates parts of XML as needed. A implementation of FCM need a serialized representation of entire XML data to can move back cursor. The XML data serialized representation could be the virtual data source.

Implementations of event-driven system allow serial access such as stream to serialized representation of XML data, by a cursor, as an element that can move along. An event-based XML parsers that implements FCM read the information pointed at by the cursor in the XML data for generating events using the method's pull event-based model around the iterator design pattern.

To back up the cursor we can use setCursorToParent() and setCursorToPreviousSibling() (if any), that moves back the cursor in the XML data. All these operations can be shown in the Figure 4.

Figure 4: Representation of performace in FCM parsers.
[Link to open this graphic in a separate page]

Cursor's values pointing to the serialized representation of XML data can be storage and manage to refresh the cursor, and go back to section previously read.

The model producer/consumer

In FCM's model producer/consumer, the application calls the parser to obtain the next parsing event, or to move back/forward the cursor. With hasNext() and next() the application know if there are more events and to take in the events, respectively.

Figure 5: Producer and Consumer to FCM.
[Link to open this graphic in a separate page]

The application, can to manage the events by demand in your role of director, and catch the event in your role of event's consumer, such as we can see as Figure 5.

In your role of director, the application, can move back and forward the cursor along the serialized representation of the XML data. With next() the applications and move forward cursor, with setCursorToParent()/setCursorToPreviousSibling() the application moves back cursor. FCM the performance gives more procedural control over the processing, allowing it to stop processing, and recreating subsection of XML data.

Supporting new operations

The FCM model offers new possibilities over pull parsing, that has been supported by new methods. This operations are relatated to set cursor to previous sections of the XML data. The new methods are the following,

  • public void setCursorToPreviousSibling(), that set cursor to previous sibling of an element, if any.
  • public void setCursorToParent(), that set cursor to parent of an element, if any.
  • public void setCursorToRoot(), that set cursor to root.

Furthermore, FCM provides the corresponding methods with a boolean result:

  • public boolean hasPreviousSibling(), that return true if the elemente in which is in any moment the cursor has previous sibling.
  • public boolean hasParent(), that return true if an element is not the root.

To skip without parsing the child, we can uses the following method:

  • public void skipWithoutParseChilds(), that allows skips subsection of the XML. This method place the cursor to the end of an element.

Example in FCM

This event-driven system takes the serialized representation of the XML data to generate event to be notified to the application. FCM can recognize events such as START_ELEMENT, START_DOCUMENT, ... specified in the XMLFCMConstants.

An example that illustrates the performance is in the Figure 6.

Figure 6: Example of execution in FCM.
   boolean flag1 = true;
   boolean flag2 = true;

   while (in.hasNext()){

       evento = in.next();

       if(evento == XMLFCMConstants.START_ELEMENT){
           if((in.getLocalName()).equals("Header")&& flag1){
               in.skipWithoutParseChilds();
               flag1 = false;
           }
           if((in.getLocalName()).equals("Fault") && flag2){
               in.setCursorToParent();
               if(in.hasPreviousSibling()){
                   in.setCursorToPreviousSibling();
                   flag2 = false;
               }
           }
       }
    }
                       

In this example we uses next()/hasNext() to iterates, and setCursorToParent()/setCursorToPreviousSibling() to go back the cursor. When we use methods to go back cursor we need control's variable, because the cursor will pass another timer over this condition, going back again.

Implementation of the model

Introduction

In this section I present an implementation realized, for J2ME CLDC[CLDC]. A requirement of this model is the need for a serialized representation of the all XML data read and to move back and forward the cursor.

The new model can use cursor's values for accessing to information previously read. StAX Section 2.3[JSR-173] diferenciates between Virtual Data Source (is data stores as XML, but not necessarily in its serialized format) and serialized representation (for supporting serial access to XML data). We can also consider the XML data given by an API, after processing XML data. If the encoding scheme and structure of all is the same (or more close for all representation) probably we can optimize the memory used.

Implementation's XML data

In J2ME CLDC, without file system to read or maintain XML data, information must be downloaded from the network, i.e. via HTTP, and must be storage in a structure to late processing. Information extracted from the network must be save in any structure quickly. To optimize memory, it is desirable not to redimensionate any structure. And it is dersirable to know the size of the strucuture where is put all XML data.

Detection of Character Encoding

According to XML Recommendation, all XML parsers must accept the UTF-8 and UTF-16 encodings of Unicode. It also gives a non-normative section to autodetection of character encodings, which includes four types for UCS-4, and 2 types for UTF-16, with or without Byte Order Mark (BOM).

Because each XML entity not accompanied by external encoding information and not in UTF-8 or UTF-16 encoding must begin with an XML encoding declaration, in which the first characters must be '<?xml', any conforming processor can detect, after two to four octets of input, which of the following cases apply. In reading this list, it may help to know that in UCS-4, '<' is "#x0000003C" and '?' is "#x0000003F", and the Byte Order Mark required of UTF-16 data streams is "#xFEFF"[Bray 04].

Taking account these consideration, in reading the previous bytes to determine the character encoding, this implementation has been implemented to give support for UTF-8, UTF-16BE, UTF-16LE, and UCS-4 and the four versions specified in XML recommendation.

Size of the structure

In HTTP we can test the Content-Length header. If the length is not provided, we may be dealing with an HTTP 1.0 server. We can use getLength() and check for a value of -1; getLength() returns a -1 to indicate that the length is not known, and then we must estimate a length.

If we know the character encoding and also know the size of data with getLength(), (HTTP 1.1), then we can stimate the size of a compact structure to manage XML data, that could be the serialized representation.

What structure?

The StringBuffer class has a constructor with an argument integer that configure internal array of char to an initial capacity. The internal structure of a StringBuffer is an array of char, and the type data char has 16 bits. Character encoding based of 8 bit (i.e., ISO- 8859-x, UTF-8, ASCII or any other 7-bit, 8-bit), does not uses the upper byte. And UCS-4 need a transformation for 16 code units, or the other.

With StringBuffer we can create a String object. When we create a String from a StringBuffer, the String points to the same character array. String has a special status in Java, and has native methods to operate that supposes a faster execution.

The method substring can be used from any other String to create a new String. This method uses a private constructor, which shares value array for speed. We can use this method to create the String object return for the API.

Well-formed XML documents

The XML 1.1 W3C Recommendation say that, "well-formedness constraint is by definition a rule which applies to all well-formed XML documents. Violations of well-formedness constraints are fatal errors."

How we can implement a structure for checking well-formed XML documents? They are implementation where XML data are extracted from the serialized representation to create a String object that is stored in an array. This process is illustrated in Figure 7.

Figure 7: A structure to support well-formed.
[Link to open this graphic in a separate page]

We observe that an object is pushed in the array increasing the depth. This size can have overflow, needs checking the size of the array, and using the method arraycopy if the size is upper.

What structure we can use to implement well-formed in FCM?

As opposed to containing the data itself, a reference is a small object containing information which refers to data elsewhere. References increase flexibility in where information can be stored, how the references are allocated, and passed between coded areas. As long as we can access any reference to the data, we can access the data, and the data themselves need not be moved. Pointers are the most powerful and efficient types of references, storing only the address of an object in memory. The mechanism of references, varying in implementation, is a fundamental programming language feature common to nearly all modern programming languages. In Java a generic reference for all kind of object is Object.

Figure 8: Structure to support well-formed in FCM.
[Link to open this graphic in a separate page]

In this picture we can see as an element can be represented as a place in an array used like stack (new Object[TAM]). An element has information around the cursor for the "place" in which begin.

We observe that any object is pushed in the array increasing the depth. This size can have overflow and need check the size of the array. If we have overflow, then we need uses System.arraycopy, to size newly the structure, taking away the previous structure.

Another possible representation to give support for FCM is the following

Figure 9: Structure choosed to support well-formed in FCM.
[Link to open this graphic in a separate page]

The information for an element is saved in an array with cursor's information for an element. A new element is inserted in this scalable structure.

How to structure information around the references

An element can be represented by a set of references, so that we can represent the hierarchical structure of an XML document. We can use a hierarchical structure to represent an XML document to structure and organize all information from the first element (the root) to any other element.

Figure 10: References of an element.
[Link to open this graphic in a separate page]

The model can be an array of references to represent an element of the XML document. The references of an element can be as follows:

  • A reference to parent (if any); note that the root is a special case. In other cases they can be a parent as follows, if (references to this element is equal to the reference to parent) then this element is the root of the XML document.
  • A reference to sibling; an element optionally can have a sibling. If the element has a sibling the reference corresponding to the sibling must have a value by means of which we can access the sibling of this element. Note that the root has no sibling.
  • A reference to child; we can access a child of this element with a reference to the child.
  • The cursor at beginning of this element; we need a value that represents the cursor at this point or that we can assign this value to the cursor and follow parse from this point. This supposes movement of the cursor to back, without loading all the document in memory.

With four references we can characterize an element and we can move back the cursor to previous the data parsed, using the references that characterize the element. And furthermore we can go back in the document, which only requires the cursor to save the value. And if we want to know if the XML document is well-formed, then we can use the value of the cursor at this point to verify if the qualified name of the start tag is the same as the end tag.

With four references we can characterize an element and we can move back the cursor to previous the data parsed, using the references that characterize the element. And furthermore we can go back in the document, which only requires the cursor to save the value. And if we want to know if the XML document is well-formed, then we can use the value of the cursor at this point to verify if the qualified name of the start tag is the same as the end tag.

Figure 11: Use of references of an element.
[Link to open this graphic in a separate page]

The interface XMLFCMConstants

This interface declares the constants used in this API. Numbers in the range 0 to 256 are reserved for the StAX specification, user defined events must use event codes outside that range.

This interface declares the constants used in this implementation. The FCM implementation can recognize following constants for associating to an event.

Figure 12: Interface XMLFCMConstants.
                XMLFCMConstants.START_ELEMENT
                XMLFCMConstants.START_DOCUMENT
                XMLFCMConstants.END_ELEMENT
                XMLFCMConstants.PROCESSING_INSTRUCTION
                XMLFCMConstants.CHARACTERS
                XMLFCMConstants.SPACE
                XMLFCMConstants.END_DOCUMENT
                XMLFCMConstants.ATTRIBUTE
                XMLFCMConstants.DTD
                XMLFCMConstants.CDATA
                XMLFCMConstants.NAMESPACE

The interface XMLFCMConstants

This implementation has a jar of 21.5 KB.

Other characteristics of the implementation

The parser has a bidirectional API. The bidirectionality is implemented in the classes XMLFCMReader and XMLFCMWriter. This implementation does not support validation but DTD is returned as a String. The implementation has support for qualified names. QName class represents XML qualified names. as defined in the XML specifications: XML Schema Part2: Datatypes specification[Schema 04], and Namespaces in XML[Namespaces]. A representation of implementation's classes is shown in the Figure 13.

Figure 13: Classes of the implementation.
\---com
    \---sierra
        +---io
        |   |   ArrayInputStream.java
        |   |   XMLReader.java
        |   |   XMLWriter.java
        |   |
        |   \---i18n
        |           ReaderUCS4.java
        |           ReaderUTF16.java
        |           ReaderUTF8.java
        |           WriterUCS4.java
        |           WriterUTF16.java
        |           WriterUTF8.java
        |
        \---xml
            |   XMLConstants.java
            |
            +---fcm
            |       Location.java
            |       XMLFCMConstants.java
            |       XMLFCMException.java
            |       XMLFCMReader.java
            |       XMLFCMWriter.java
            |
            \---namespace
                    NamespaceContext.java
                    QName.java

The cursor in this implementation is an integer. We can consider this valueas an object by means of the Integer class of java.lang.

Validation

This section shows the validation of the model. The implementation presented in the previous section is compared to another implementation with other models for the same Java platform (J2ME).

Introduction

They are Java parsers that they were originally designed for use with embedded Java applications or Java applets, and with some modifications, they should be able to fit in the J2ME MIDP's resource-constrained environment. Some XML parsers were originally written for J2SE, they have been ported to J2ME MIDP and they can be used with MIDlet applications. In J2ME MIDP environment, developers must constantly be aware of the CPU and memory usage of their applications. Using XML parsers along with your applications creates a storage overhead of 10KB to 30KB.

All test has been realized over the emulator Wireless Toolkit. The scenario is in a PC, with the emulator that requests a XML file to the server, the file is download and processed. To evaluate the performance of the parser we can see the temporal evolution of the memory, and we can be evaluated with different parsing models. The size of XML file is a parameter that we can change to evaluate the performance.

To avoid degradation of the measures of memory, the application does not maintain any structure around the data, all data is get and shown at screen of devices of the emulator, so the test shown the internal memory to parsing XML data.

Performance of FCM's implementation

We are uses an XML file of 17024 Bytes to see how is the peformance of the FCM's implementation. The axes of the picture are time, and memory used. The temporal evolution of the memory is shown in the Figure 14.

Figure 14: Test with FCM in Wireless Toolkit.
[Link to open this graphic in a separate page]

In the picture we can see an initial part related to object's initialization. After we can see a step that suposes the process of reading data from the network. After that is the process of parsing data.

This model separates the memory used by the serialized representation of the XML and the memory used to parse this data. And can give a good vision of the cost of support XML serialized, and the support of XML processing by the parse. This picture also gives measures of the time used to processing and to read XML data.

Data is read from the network, similarly to performance of DataInputStream's methods, i. e., realizing a composition of the a character from one or two byte read from the stream, to fit the structure used in the parser. This structure supposes the serialized representation of the parser. The size of serialized representation of the XML data has size comparatively less than the size of the structures supported for XML parsing. Furthermore, the method skipWithoutParsingChilds(), supposes a cost in bytecode executed but not memory used to parsing subsection of the XML data.

Relating the performance with another parser

We have choosen another parsers to evalidate the performance of the implementation. The parser has been choosed as representation of the models of parsing, i.e., Model, Push and Pull. They are the following

The test has been made with small and big size of the file.

Test with small file

The size of the XML file is 1728 bytes. The test has been realized for the 4 parsers.

Figure 15: Test with small file.
[Link to open this graphic in a separate page]

The parser that represent pull has the best memory performance. The parser that represent model parser has the worst memory performance.

Test with big file

In the next picture the size of the XML file is 24458 bytes. The parser that represent model and push parser consumes all memory available for the emulator. The pull parser has a better performance.

Figure 16: Test with big file.
[Link to open this graphic in a separate page]

All this measures has been realized for the worst case of FCM that support parsing controlled, allowing skip subsection of the XML. FCM give support to encoding different to the 8 bit supported by kxml2.

Conclusions

This paper presents a new model to parse XML documents based on the free cursor mobility. This low-level parsing model need support for a XML data serialized representation. This model has been presented in a framework of platforms with resource-constrained or limited memory. This model preserves the cursor of the pull parse model but adds the ability to move the cursor back.


Acknowledgments

Thank to B. Tommie Usdin for all help provided.

Thank to Sam Wilmott for suggestions and criticism.

Thank to Ian E. Gorman to support this work.


Bibliography

[Bray 04] Tim Bray et al., "Extensible Markup Language (XML)", W3C Recommendation 04 February 2004, edited in place 15 April 2004, http://www.w3.org/TR/xml11/.

[Brownell 02] David Brownell, "SAX2", January 2002, O'Reilly, ISBN: 0-596-00237-8.

[CLDC] Java Specification Requests (JSR) 139, Connected, Limited Device Configuration 1.1, http://jcp.org/en/jsr/detail?id=139.

[DOM] "Document Object Model", http://www.w3.org/DOM/

[J2ME] Java 2 Platform, Micro Edition (J2ME), "http://java.sun.com/j2me/index.jsp".

[JSR-172] Java Specification Request 172: J2ME Web Services Specification, "http://jcp.org/en/jsr/detail?id=172".

[JSR-173] BEA Systems, Inc., "Java Specification Requests 173: Streaming API for XML", http://jcp.org/en/jsr/detail?id=173.

[Knudsen 02] Jonathan Knudsen,"Parsing XML in J2ME" http://developers.sun.com/techtopics/mobility/midp/articles/parsingxml/, 2002.

[kXML2] kXML2, "http://kxml.objectweb.org/".

[Megginson] D. Megginson et al. "SAX 2.0: The Simple API for XML", http://www.saxproject.org.

[MinML] MinML, "http://www.wilson.co.uk/xml/minml.htm".

[Namespaces] Namespaces in XML, W3C 14 January 1999.

[Pull] XML Pull Parsing, "http://www.xmlpull.org".

[Schema 04] XML Schema Part2: Datatypes specification, http://www.w3.org/TR/xmlschema-2/.

[Sosnoski 01] Dennis M. Sosnoski," XML and Java technologies: Document models, Part 1: Performance "http://www-106.ibm.com/developerworks/xml/library/x-injava/", 2001.

[TAMparser] TAM - The Tiny API for Markup. http://simonstl.com/projects/tam/.

[Xparse-J] Xparse-J 1.0, "http://www.webreference.com/xml/tools/xparse-j.html".



A New Paradigm of Parsing XML based on Free Cursor Mobility (FCM)

Antonio J. Sierra [Assistant Professor, University of Sevilla, Escuela Superior de IngenierosDepartament of Sistemas and AutomaticArea of Engineering Telematic]
antonio@trajano.us.es