Action against software patentsGnome2 LogoW3C LogoRed Hat Logo
Made with Libxml2 Logo

The XML C parser and toolkit of Gnome

I/O Interfaces

Developer Menu
API Indexes
Related links

Table of Content:

  1. General overview
  2. The basic buffer type
  3. Input I/O handlers
  4. Output I/O handlers
  5. The entities loader
  6. Example of customized I/O

General overview

The module xmlIO.hprovidesthe interfaces to the libxml2 I/O system. This consists of 4 main parts:

  • Entities loader, this is a routine which tries to fetch the entities(files) based on their PUBLIC and SYSTEM identifiers. The default loaderdon't look at the public identifier since libxml2 do not maintain acatalog. You can redefine you own entity loader by usingxmlGetExternalEntityLoader()andxmlSetExternalEntityLoader(). Check theexample.
  • Input I/O buffers which are a commodity structure used by the parser(s)input layer to handle fetching the informations to feed the parser. Thisprovides buffering and is also a placeholder where the encodingconverters to UTF8 are piggy-backed.
  • Output I/O buffers are similar to the Input ones and fulfill similartask but when generating a serialization from a tree.
  • A mechanism to register sets of I/O callbacks and associate them withspecific naming schemes like the protocol part of the URIs.

    This affect the default I/O operations and allows to use specific I/Ohandlers for certain names.

The general mechanism used when loading http://rpmfind.net/xml.html forexample in the HTML parser is the following:

  1. The default entity loader calls xmlNewInputFromFile()withthe parsing context and the URI string.
  2. the URI string is checked against the existing registered handlersusing their match() callback function, if the HTTP module was compiledin, it is registered and its match() function will succeeds
  3. the open() function of the handler is called and if successful willreturn an I/O Input buffer
  4. the parser will the start reading from this buffer and progressivelyfetch information from the resource, calling the read() function of thehandler until the resource is exhausted
  5. if an encoding change is detected it will be installed on the inputbuffer, providing buffering and efficient use of the conversionroutines
  6. once the parser has finished, the close() function of the handler iscalled once and the Input buffer and associated resources aredeallocated.

The user defined callbacks are checked first to allow overriding of thedefault libxml2 I/O routines.

The basic buffer type

All the buffer manipulation handling is done using thexmlBuffertype define in tree.hwhich is aresizable memory buffer. The buffer allocation strategy can be selected to beeither best-fit or use an exponential doubling one (CPU vs. memory usetrade-off). The values are XML_BUFFER_ALLOC_EXACTandXML_BUFFER_ALLOC_DOUBLEIT, and can be set individually or on asystem wide basis using xmlBufferSetAllocationScheme(). A numberof functions allows to manipulate buffers with names starting with thexmlBuffer...prefix.

Input I/O handlers

An Input I/O handler is a simple structurexmlParserInputBuffercontaining a context associated to theresource (file descriptor, or pointer to a protocol handler), the read() andclose() callbacks to use and an xmlBuffer. And extra xmlBuffer and a charsetencoding handler are also present to support charset conversion whenneeded.

Output I/O handlers

An Output handler xmlOutputBufferis completely similar to anInput one except the callbacks are write() and close().

The entities loader

The entity loader resolves requests for new entities and create inputs forthe parser. Creating an input from a filename or an URI string is donethrough the xmlNewInputFromFile() routine. The default entity loader do nothandle the PUBLIC identifier associated with an entity (if any). So it justcalls xmlNewInputFromFile() with the SYSTEM identifier (which is mandatory inXML).

If you want to hook up a catalog mechanism then you simply need tooverride the default entity loader, here is an example:

#include <libxml/xmlIO.h>

xmlExternalEntityLoader defaultLoader = NULL;

xmlParserInputPtr
xmlMyExternalEntityLoader(const char *URL, const char *ID,
                               xmlParserCtxtPtr ctxt) {
    xmlParserInputPtr ret;
    const char *fileID = NULL;
    /* lookup for the fileID depending on ID */

    ret = xmlNewInputFromFile(ctxt, fileID);
    if (ret != NULL)
        return(ret);
    if (defaultLoader != NULL)
        ret = defaultLoader(URL, ID, ctxt);
    return(ret);
}

int main(..) {
    ...

    /*
     * Install our own entity loader
     */
    defaultLoader = xmlGetExternalEntityLoader();
    xmlSetExternalEntityLoader(xmlMyExternalEntityLoader);

    ...
}

Example of customized I/O

This example come from areal use case, xmlDocDump() closes the FILE * passed by the applicationand this was a problem. The solutionwas to redefine anew output handler with the closing call deactivated:

  1. First define a new I/O output allocator where the output don't closethe file:
    xmlOutputBufferPtr
    xmlOutputBufferCreateOwn(FILE *file, xmlCharEncodingHandlerPtr encoder) {
        xmlOutputBufferPtr ret;
        
        if (xmlOutputCallbackInitialized == 0)
            xmlRegisterDefaultOutputCallbacks();
    
        if (file == NULL) return(NULL);
        ret = xmlAllocOutputBuffer(encoder);
        if (ret != NULL) {
            ret->context = file;
            ret->writecallback = xmlFileWrite;
            ret->closecallback = NULL;  /* No close callback */
        }
        return(ret);
    } 
  2. And then use it to save the document:
    FILE *f;
    xmlOutputBufferPtr output;
    xmlDocPtr doc;
    int res;
    
    f = ...
    doc = ....
    
    output = xmlOutputBufferCreateOwn(f, NULL);
    res = xmlSaveFileTo(output, doc, NULL);
        

Daniel Veillard