Expat is a library, written in C, for parsing XML documents. It's the
underlying XML parser for the open source Mozilla project, perl's
XML::Parser, and other open-source XML parsers.
This library is the creation of James Clark, who's also given us
groff (an nroff look-alike), Jade (an implemention of ISO's DSSSL stylesheet
language for SGML), XP (a Java XML parser package), XT (a Java XSL engine).
James was also the technical lead on the XML Working Group at W3 that produced
the XML specification.
The bulk of this document was originally commissioned as an article by
XML.com. They graciously allowed me to retain
copyright and to distribute it with expat.
Expat is a stream-oriented parser. You register callback (or handler)
functions with
the parser and then start feeding it the document.
As the parser recognizes parts of
the document, it will call the appropriate handler for that part (if you've
registered one.) The document is fed to the parser in pieces, so you can
start parsing before you have all the document. This also allows you to
parse really huge documents that won't fit into memory.
Expat can be intimidating due to the many kinds of handlers and options
you can set. But you only need to learn four functions in order to do 90%
of what you'll want to do with it:
XML_ParserCreate
Create a new parser object.
XML_SetElementHandler
Set handlers for start and end tags.
XML_SetCharacterDataHandler
Set handler for text.
XML_Parse
Pass a buffer full of document to the parser
These functions and others are described in the
reference part of this document. The reference
section also describes in detail the parameters passed to the different
types of handlers.
Let's look at a very simple example program that only uses 3 of the above
functions (it doesn't need to set a character handler.) The program
outline.c
prints an element outline, indenting child elements to distinguish them from
the parent element that contains them. The start handler does all the work.
It prints two indenting spaces for every level of ancestor elements, then
it prints the element and attribute information. Finally it increments the
global Depth variable.
int Depth;
void
start(void *data, const char *el, const char **attr) {
int i;
for (i = 0; i < Depth; i++)
printf(" ");
printf("%s", el);
for (i = 0; attr[i]; i += 2) {
printf(" %s='%s'", attr[i], attr[i + 1]);
}
printf("\n");
Depth++;
} /* End of start handler */
The end tag simply does the bookkeeping work of decrementing the Depth.
void
end(void *data, const char *el) {
Depth--;
} /* End of end handler */
After creating the parser, the main program just has the job of
shoveling the document to the parser so that it can do its work.
The expat distribution comes as a compressed (with GNU gzip) tar file.
You may download the latest version from
Source Forge.
After unpacking this, cd into the directory. Then follow either the
Win32 directions or Unix directions below.
Building under Win32
If you're using the GNU compiler under cygwin, follow the Unix directions
in the next section. Otherwise if you have Microsoft's Developer Studio
installed, then from Windows Explorer double-click on "expat.dsp" in the
lib directory and build and install in the usual manner.
Alternatively, you may download the win32 binary package that contains
the expat.h include file and a pre-built dll.
Building under Unix (or GNU)
First you'll need to run the configure shell script in order to configure
the Makefiles and headers for your system.
If you're happy with all the defaults that configure picks for you,
and you have permission on your system to install into /usr/local, you can
install expat with this sequence of commands:
./configure
make
make install
There are some options that you can provide to this script, but the
only one we'll mention here is the --prefix option. You can
find out all the options available by running configure with just the
--help option.
By default, the configure script sets things up so that the library gets
installed in /usr/local/lib and the associated header file in
/usr/local/include.
But if you were to give the option, --prefix=/home/me/mystuff,
then the library and header would get installed in
/home/me/mystuff/lib and /home/me/mystuff/include
respectively.
Unless you installed expat in a location not expected by your compiler
and linker, all you have to do to use expat in your programs is to include
the expat header (#include <expat.h>) in your files that
make calls to it and to tell the linker
that it needs to link against the expat library. On Unix systems, this would
be the -lexpat argument.
Otherwise, you'll need to tell the compiler where to look for the expat header
and the linker where to find the expat library. You may also need to take
steps to tell the operating system where to find this libary at run time.
On a Unix based system, here's what a Makefile might look like when expat
is installed in a standard location:
You'd also have to set the environment variable LD_LIBRARY_PATH
to /home/me/mystuff/lib (or to
${LD_LIBRARY_PATH}:/home/me/mystuff/lib if LD_LIBRARY_PATH
already has some directories in it) in order to run your application.
Expat Basics
As we saw in the example in the overview, the first step in parsing an
XML document with expat is to create a parser object. There are
three functions in the expat API for creating a
parser object.
However, only two of these
(XML_ParserCreate and
XML_ParserCreateNS)
can be used for constructing a parser for a top-level document.
The object returned by these functions is an opaque pointer
(i.e. expat.h declares it as void *) to data with further internal structure.
In order to free the memory associated with this object you must call
XML_ParserFree. Note that if
you have provided any user data that gets stored
in the parser, then your application is responsible for freeing it prior to
calling XML_ParserFree.
The objects returned by the parser creation functions are good for
parsing only one XML document or external parsed entity. If your application
needs to parse many XML documents, then it needs to create a parser object
for each one. The best way to deal with this is to create a higher level
object that contains all the default initialization you want for your parser
objects.
Walking through a document hierarchy with a stream oriented parser will
require a good stack mechanism in order to keep track of current context.
For instance, to answer the simple question,
"What element does this text belong to?" requires a stack, since the
parser may have descended into other elements that are children of the
current one and has encountered this text on the way out.
The things you're likely to want to keep on a stack are the currently
opened element and it's attributes. You push this information onto the
stack in the start handler and you pop it off in the end handler.
For some tasks, it is sufficient to just keep information on what the
depth of the stack is (or would be if you had one.) The outline program shown
above presents one example. Another such task would be skipping over a
complete element. When you see the start tag for the element you want to
skip, you set a skip flag and record the depth at which the element started.
When the end tag handler encounters the same depth, the skipped element has
ended and the flag may be cleared. If you follow the convention that the
root element starts at 1, then you can use the same variable for skip flag
and skip depth.
void
init_info(Parseinfo *info) {
info->skip = 0;
info->depth = 1;
/* Other initializations here */
} /* End of init_info */
void
rawstart(void *data, const char *el, const char **attr) {
Parseinfo *inf = (Parseinfo *) data;
if (! inf->skip) {
if (should_skip(inf, el, attr)) {
inf->skip = inf->depth;
}
else
start(inf, el, attr); /* This does rest of start handling */
}
inf->depth++;
} /* End of rawstart */
void
rawend(void *data, const char *el) {
Parseinfo *inf = (Parseinfo *) data;
inf->depth--;
if (! inf->skip)
end(inf, el); /* This does rest of end handling */
if (inf->skip == inf->depth)
inf->skip = 0;
} /* End rawend */
Notice in the above example the difference in how depth is manipulated
in the start and end handlers. The end tag handler should be the mirror
image of the start tag handler. This is necessary to properly model
containment. Since, in the start tag handler, we
incremented depth after the main body of start tag code, then in
the end handler, we need to manipulate it before the main body.
If we'd decided to increment it first thing in the start handler, then
we'd have had to decrement it last thing in the end handler.
Communicating between handlers
In order to be able to pass information between different handlers
without using globals, you'll need to define a data structure to hold
the shared variables. You can then tell expat (with the XML_SetUserData
function) to pass a pointer to this
structure to the handlers. This is typically the first argument received
by most handlers.
Namespace Processing
When the parser is created using the XML_ParserCreateNS,
function, expat performs namespace processing. Under namespace processing,
expat consumes xmlns and xmlns:... attributes,
which declare namespaces for the scope of the element in which they
occur. This means that your start handler will not see these attributes.
Your application can still be informed of these declarations by setting
namespace declaration handlers with
XML_SetNamespaceDeclHandler.
Element type and attribute names that belong to a given namespace are
passed to the appropriate handler in expanded form. By default this expanded
form is a concatenation of the namespace URI, the separator character (which
is the 2nd argument to XML_ParserCreateNS), and the local
name (i.e. the part after the colon). Names with undeclared prefixes are
passed through to the handlers unchanged, with the prefix and colon still
attached. Unprefixed attribute names are never expanded, and unprefixed
element names are only expanded when they are in the scope of a default
namespace.
However if XML_SetReturnNSTriplet
has been called with a non-zero do_nst parameter, then the
expanded form for names with an explicit prefix is a concatenation of:
URI, separator, local name, separator, prefix.
You can set handlers for the start of a namespace declaration and for
the end of a scope of a declaration with the
XML_SetNamespaceDeclHandler function.
The StartNamespaceDeclHandler is called prior to the start tag handler
and the EndNamespaceDeclHandler is called before the corresponding end tag
that ends the namespace's scope.
The namespace start handler gets passed the prefix and URI for the namespace.
For a default namespace declaration (xmlns='...'), the prefix will be null.
The URI will be null for the case where the default namespace is being unset.
The namespace end handler just gets the prefix for the closing scope.
These handlers are called for each declaration. So if, for instance, a
start tag had three namespace declarations, then the StartNamespaceDeclHandler
would be called three times before the start tag handler is called, once for
each declaration.
The namespace.c example demonstrates the
use of these features. Like outline.c, it produces an outline, but
in addition it annotates when a namespace scope starts and when it ends.
This example also demonstrates use of application user data.
Character Encodings
While XML is based on Unicode, and every XML processor is required to
recognized UTF-8 and UTF-16 (1 and 2 byte encodings of Unicode), other
encodings may be declared in XML documents or entities. For the main
document, an XML declaration may contain an encoding declaration:
<?xml version="1.0" encoding="ISO-8859-2"?>
External parsed entities may begin with a text declaration, which
looks like an XML declaration with just an encoding declaration:
<?xml encoding="Big5"?>
With expat, you may also specify an encoding at the time of creating a
parser. This is useful when the encoding information may come from a source
outside the document itself (like a higher level protocol.)
There are four built-in encodings in expat:
UTF-8
UTF-16
ISO-8859-1
US-ASCII
Anything else discovered in an encoding declaration or in the
protocol encoding specified in the parser constructor, triggers a call
to the UnknownEncodingHandler. This handler gets passed
the encoding name and a pointer to an XML_Encoding data
structure. Your handler must fill in this structure and return 1 if
it knows how to deal with the encoding. Otherwise the handler should
return 0.
The handler also gets passed a pointer to an
optional application data structure that you may indicate when you set
the handler.
Expat places restrictions on character encodings that it can support
by filling in the XML_Encoding structure.
include file:
Every ASCII character that can appear in a well-formed XML document
must be represented by a single byte, and that byte must correspond to
it's ASCII encoding (except for the characters $@@\^'{}~)
Characters must be encoded in 4 bytes or less.
All characters encoded must have Unicode scalar values less than or
equal to 65535 (0xFFFF)This does not apply to the built-in support
for UTF-16 and UTF-8
No character may be encoded by more that one distinct sequence of
bytes
XML_Encoding contains an array of integers that correspond
to the 1st byte of an encoding sequence. If the value in the array for a
byte is zero or positive, then the byte is a single byte encoding that
encodes the Unicode scalar value contained in the array. A -1 in this array
indicates a malformed byte. If the value is
-2, -3, or -4, then the byte is the beginning of a 2, 3, or 4 byte sequence
respectively. Multi-byte sequences are sent to the convert function pointed
at in the XML_Encoding structure. This function should return
the Unicode scalar value for the sequence or -1 if the sequence is malformed.
One pitfall that novice expat users are likely to fall into is that
although expat may accept input in various encodings, the strings that it
passes to the handlers are always encoded in UTF-8. Your application is
responsible for any translation of these strings into other encodings.
Handling External Entity References
Expat does not read or parse external entities directly. Note that any
external DTD is a special case of an external entity.
If you've set no ExternalEntityRefHandler, then external
entity references are silently ignored. Otherwise, it calls your handler with
the information needed to read and parse the external entity.
Your handler
isn't actually responsible for parsing the entity, but it is responsible
for creating a subsidiary parser with
XML_ExternalEntityParserCreate that will do the job. This returns
an instance of XML_Parser that has handlers and other data
structures initialized from the parent parser. You may then use
XML_Parse or XML_ParseBuffer calls against this
parser.
Since external entities my refer to other external entities, your handler
should be prepared to be called recursively.
Parsing DTDs
In order to parse parameter entities, before starting the parse, you must
call XML_SetParamEntityParsing with one of the following
arguments:
XML_PARAM_ENTITY_PARSING_NEVER
Don't parse parameter entities or the external subset
XML_PARAM_ENTITY_PARSING_UNLESS_STANDALONE
Parse parameter entites and the external subset unless
standalone was set to "yes" in the XML declaration.
XML_PARAM_ENTITY_PARSING_ALWAYS
Always parse parameter entities and the external subset
In order to read an external DTD, you also have to set an
external entity reference handler as described above.
Construct a new parser. If encoding is non-null, it specifies a
character encoding to use for the document. This overrides the document
encoding declaration. There are four built-in encodings:
US-ASCII
UTF-8
UTF-16
ISO-8859-1
Any other value will invoke a call to the UnknownEncodingHandler.
Constructs a new parser that has namespace processing in effect. Namespace
expanded element names and attribute names are returned as a concatenation
of the namespace URI, sep, and the local part of the name. This
means that you should pick a character for sep that can't be
part of a legal URI.
Construct a new parser using the suite of memory handling functions
specified in ms. If ms is NULL, then use the
standard set of memory management functions. If sep is
non NULL, then namespace processing is enabled in the created parser
and the character pointed at by sep is used as the separator between
the namespace URI and the local part of the name
Construct a new XML_Parser object for parsing an external general
entity. Context is the context argument passed in a call to a
ExternalEntityRefHandler. Other state information such as handlers, user data,
namespace processing is inherited from the parser passed as the 1st
argument. So you shouldn't need to call any of the behavior changing
functions on this parser (unless you want it to act differently than the
parent parser.)
Parse some more of the document. The string s is a buffer
containing part (or perhaps all) of the document. The number of bytes of s
that are part of the document is indicated by len. This means
that s doesn't have to be null terminated. It also means that
if len is larger than the number of bytes in the block of
memory that s points at, then a memory fault is likely. The
isFinal parameter informs the parser that this is the last
piece of the document. Frequently, the last piece is empty (i.e.
len is zero.)
If a parse error occurred, it returns 0. Otherwise it returns a non-zero
value.
This is just like XML_Parse, except in this case expat provides the buffer.
By obtaining the buffer from expat with the XML_GetBuffer
function, the application can avoid double copying of the input.
Obtain a buffer of size len to read a piece of the document
into. A NULL value is returned if expat can't allocate enough memory for
this buffer. This has to be called prior to every call to
XML_ParseBuffer. A typical use would look like this:
for (;;) {
int bytes_read;
void *buff = XML_GetBuffer(p, BUFF_SIZE);
if (buff == NULL) {
/* handle error */
}
bytes_read = read(docfd, buff, BUFF_SIZE);
if (bytes_read < 0) {
/* handle error */
}
if (! XML_ParseBuffer(p, bytes_read, bytes_read == 0)) {
/* handle parse error */
}
if (bytes_read == 0)
break;
}
Although handlers are typically set prior to parsing and left alone, an
application may choose to set or change the handler for a parsing event
while the parse is in progress. For instance, your application may choose
to ignore all text not descended from a para element. One
way it could do this is to set the character handler when a para start tag
is seen, and unset it for the corresponding end tag.
A handler may be unset by providing a NULL pointer to the
appropriate handler setter. None of the handler setting functions have
a return value.
Your handlers will be receiving strings in arrays of type
XML_Char. This type is defined in expat.h as char *
and contains bytes encoding UTF-8.
Note that you'll receive them in this form independent of the original
encoding of the document.
Set handler for start (and empty) tags. Attributes are passed to the start
handler as a pointer to a vector of char pointers. Each attribute seen in
a start (or empty) tag occupies 2 consecutive places in this vector: the
attribute name followed by the attribute value. These pairs are terminated
by a null pointer.
Note that an empty tag generates a call to both start and end handlers
(in that order).
typedef void
(*XML_CharacterDataHandler)(void *userData,
const XML_Char *s,
int len);
Set a text handler. The string your handler receives
is NOT zero terminated. You have to use the length argument
to deal with the end of the string. A single block of contiguous text
free of markup may still result in a sequence of calls to this handler.
In other words, if you're searching for a pattern in the text, it may
be split across calls to this handler.
Set a handler for processing instructions. The target is the first word
in the processing instruction. The data is the rest of the characters in
it after skipping all whitespace after the initial word.
typedef void
(*XML_DefaultHandler)(void *userData,
const XML_Char *s,
int len);
Sets a handler for any characters in the document which wouldn't
otherwise be handled. This includes both data for which no handlers can be
set (like some kinds of DTD declarations) and data which could be reported
but which currently has no handler set. Note that a contiguous piece of
data that is destined to be reported to the default handler may actually
be reported over several calls to the handler. Setting the handler with
this call has the side effect of turning off expansion of references
to internally defined general entities. Instead these references are
passed to the default handler.
Set an external entity reference handler. This handler is also
called for processing an external DTD subset if parameter entity parsing
is in effect. (See XML_SetParamEntityParsing.)
The base parameter is the base to use for relative system identifiers.
It is set by XML_SetBase and may be null. The
public id parameter is the public id given in the entity declaration and
may be null. The system id is the system identifier specified in the entity
declaration and is never null.
There are a couple of ways in which this handler differs from others.
First, this handler returns an integer. A non-zero value should be returned
for successful handling of the external entity reference. Returning a zero
indicates failure, and causes the calling parser to return
an XML_ERROR_EXTERNAL_ENTITY_HANDLING error.
Second, instead of having userData as its first argument, it receives the
parser that encountered the entity reference. This, along with the context
parameter, may be used as arguments to a call to
XML_ExternalEntityParserCreate.
Using the returned parser, the body of the external entity can be recursively
parsed.
Since this handler may be called recursively, it should not be saving
information into global or static variables.
typedef int
(*XML_UnknownEncodingHandler)(void *encodingHandlerData,
const XML_Char *name,
XML_Encoding *info);
Set a handler to deal with encodings other than the
built in set. If the handler knows how
to deal with an encoding with the given name, it should fill in the info
data structure and return 1. Otherwise it should return 0.
typedef struct {
int map[256];
void *data;
int (*convert)(void *data, const char *s);
void (*release)(void *data);
} XML_Encoding;
The map array contains information for every possible possible leading
byte in a byte sequence. If the corresponding value is >= 0, then it's
a single byte sequence and the byte encodes that Unicode value. If the
value is -1, then that byte is invalid as the initial byte in a sequence.
If the value is -n, where n is an integer > 1, then n is the number of
bytes in the sequence and the actual conversion is accomplished by a
call to the function pointed at by convert. This function may return -1
if the sequence itself is invalid. The convert pointer may be null if
there are only single byte codes. The data parameter passed to the convert
function is the data pointer from XML_Encoding. The string s is NOT
null terminated and points at the sequence of bytes to be converted.
The function pointed at by release is called by the parser when it is
finished with the encoding. It may be null.
Set a handler to be called when a namespace is declared. Namespace
declarations occur inside start tags. But the namespace declaration start
handler is called before the start tag handler for each namespace declared
in that start tag.
Set a handler to be called when leaving the scope of a namespace
declaration. This will be called, for each namespace declaration, after
the handler for the end tag of the element in which the namespace was declared.
Sets a handler that is called for XML declarations and also for
text declarations discovered in external entities. The way to distinguish
is that the version parameter will be NULL for text
declarations. The encoding parameter may be NULL for
an XML declaration. The standalone argument will contain
-1, 0, or 1 indicating respectively that there was no standalone parameter in
the declaration, that it was given as no, or that it was given as yes.
Set a handler that is called at the start of a DOCTYPE declaration,
before any external or internal subset is parsed. Both sysid
and pubid may be NULL. The has_internal_subset
will be non-zero if the DOCTYPE declaration has an internal subset.
Sets a handler for element declarations in a DTD. The handler gets called
with the name of the element in the declaration and a pointer to a structure
that contains the element model. It is the application's responsibility to
free this data structure.
The model argument is the root of a tree of
XML_Content nodes. If type equals
XML_CTYPE_EMPTY or XML_CTYPE_ANY, then
quant will be XML_CQUANT_NONE, and the other fields
will be zero or NULL.
If type is XML_CTYPE_MIXED, then quant
will be XML_CQUANT_NONE or XML_CQUANT_REP and
numchildren will contain the number of elements that are allowed
to be mixed in and children points to an array of
XML_Content structures that will all have type XML_CTYPE_NAME
with no quantification.
Only the root node can be type XML_CTYPE_EMPTY, XML_CTYPE_ANY, or XML_CTYPE_MIXED.
For type XML_CTYPE_NAME, the name field points
to the name and the numchildren and children fields
will be zero and NULL. The quant field will indicate any
quantifiers placed on the name.
Types XML_CTYPE_CHOICE and XML_CTYPE_SEQ
indicate a choice or sequence respectively. The numchildren
field indicates how many nodes in the choice or sequence and
children points to the nodes.
Set a handler for attlist declarations in the DTD. This handler is called
for each attribute. So a single attlist declaration with multiple
attributes declared will generate multiple calls to this handler. The
elname parameter returns the name of the element for which the
attribute is being declared. The attribute name is in the attname
parameter. The attribute type is in the att_type parameter.
It is the string representing the type in the declaration with whitespace
removed.
The dflt parameter holds the default value. It will
be NULL in the case of "#IMPLIED" or "#REQUIRED" attributes. You can
distinguish these two cases by checking the isrequired
parameter, which will be true in the case of "#REQUIRED" attributes.
Attributes which are "#FIXED" will have also have a true
isrequired, but they will have the non-NULL fixed value in the
dflt parameter.
Sets a handler that will be called for all entity declarations.
The is_parameter_entity argument will be non-zero in the case
of parameter entities and zero otherwise.
For internal entities (<!ENTITY foo "bar">),
value will be non-NULL and systemId,
publicId, and notationName will all be NULL.
The value string is not NULL terminated; the length is provided in
the value_length parameter. Do not use value_length
to test for internal entities, since it is legal to have zero-length
values. Instead check for whether or not value is NULL.
The notationName argument will have a non-NULL value only
for unparsed entity declarations.
typedef int
(*XML_NotStandaloneHandler)(void *userData);
Set a handler that is called if the document is not "standalone".
This happens when there is an external subset or a reference to a parameter
entity, but does not have standalone set to "yes" in an XML declaration.
If this handler returns 0, then the parser will throw an
XML_ERROR_NOT_STANDALONE error.
These are the functions you'll want to call when the parse functions
return 0 (i.e. a parse error has ocurred), although the position reporting
functions are useful outside of errors. The position reported is the byte
position (in the original document or entity encoding) of the first of the
sequence of characters that generated the current event (or the error that
caused the parse functions to return 0.)
The position reporting functions are accurate only outside of the DTD.
In other words, they usually return bogus information when called from within
a DTD declaration handler.
Returns the parser's input buffer, sets the integer pointed at by
offset to the offset within this buffer of the current
parse position, and set the integer pointed at by size
to the size of the returned buffer.
This should only be called from within a handler during an active
parse and the returned buffer should only be referred to from within
the handler that made the call. This input buffer contains the untranslated
bytes of the input.
Only a limited amount of context is kept, so if the event triggering
a call spans over a very large amount of input, the actual parse position
may be before the beginning of the buffer.
This sets the user data pointer that gets passed to handlers.
It overwrites any previous value for this pointer. Note that the
application is responsible for freeing the memory associated with
userData when it is finished with the parser. So if
you call this when there's already a pointer there, and you haven't
freed the memory associated with it, then you've probably just leaked
memory.
After this is called, handlers receive the parser in the
userData argument. The userData information can still be obtained using
the XML_GetUserData function.
Set the base to be used for resolving relative URIs in system identifiers.
The return value is 0 if there's no memory to store base, otherwise it's
non-zero.
When attributes are reported to the start handler in the atts vector,
attributes that were explicitly set in the element occur before any
attributes that receive their value from default information in an
ATTLIST declaration. This function returns the number of attributes that
were explicitly set times two, thus giving the offset in the atts
array passed to the start tag handler of the first attribute set
due to defaults. It supplies information for the last call to a start
handler. If called inside a start handler, then that means the current call.
Returns the index of the ID attribute passed in the atts array
in the last call to XML_StartElementHandler, or -1 if there is no ID
attribute. If called inside a start handler, then that means the current call.
Set the encoding to be used by the parser. It is equivalent to
passing a non-null encoding argument to the parser creation functions.
It must not be called after XML_Parser or XML_ParseBuffer have been
called on the given parser.
This enables parsing of parameter entities, including the external
parameter entity that is the external DTD subset, according to
code.
The choices for code are:
This function only has an effect when using a parser created with
XML_ParserCreateNS, i.e. when namespace
processing is in effect. The do_nst sets whether or not prefixes
are returned with names qualified with a namespace prefix. If this function
is called with do_nst non-zero, then afterwards namespace
qualified names (that is qualified with a prefix as opposed to belonging
to a default namespace) are returned as a triplet with the three parts
separated by the namespace separator specified when the parser was created.
The order of returned parts is URI, local name, and prefix.
If do_nst is zero, then namespaces are reported in the
default manner, URI then local_name separated by the namespace separator.
Return the library version information as a structure.
typedef struct {
int major;
int minor;
int micro;
} XML_Expat_Version;
Some macros are also defined that support compile-time tests of the
library version:
XML_MAJOR_VERSION
XML_MINOR_VERSION
XML_MICRO_VERSION
Testing these constants is currently the best way to determine if
particular parts of the Expat API are available.
@
1.1
log
@Initial revision
@
text
@@
1.1.1.1
log
@Import of XFree86 4.3.0.
@
text
@@
1.1.1.2
log
@Import of XFree86 4.4.0.
@
text
@d1 2
a2 3
d5 1
d11 3
a13 3
d18 3
a20 4
Expat is a library, written in C, for parsing XML documents. It's
the underlying XML parser for the open source Mozilla project, Perl's
XML::Parser, Python's xml.parsers.expat, and
other open-source XML parsers.
d23 8
a30 8
groff (an nroff look-alike), Jade (an implemention of ISO's DSSSL
stylesheet language for SGML), XP (a Java XML parser package), XT (a
Java XSL engine). James was also the technical lead on the XML
Working Group at W3C that produced the XML specification.
This is free software, licensed under the MIT/X Consortium license. You may download it
from the Expat home page.
d34 2
a35 2
XML.com. They graciously allowed
Clark Cooper to retain copyright and to distribute it with Expat.
Expat is a stream-oriented parser. You register callback (or
handler) functions with the parser and then start feeding it the
document. As the parser recognizes parts of the document, it will
call the appropriate handler for that part (if you've registered one.)
The document is fed to the parser in pieces, so you can start parsing
before you have all the document. This also allows you to parse really
huge documents that won't fit into memory.
Expat can be intimidating due to the many kinds of handlers and
options you can set. But you only need to learn four functions in
order to do 90% of what you'll want to do with it:
These functions and others are described in the reference part of this document. The reference
section also describes in detail the parameters passed to the
different types of handlers.
Let's look at a very simple example program that only uses 3 of the
above functions (it doesn't need to set a character handler.) The
program outline.c prints an
element outline, indenting child elements to distinguish them from the
parent element that contains them. The start handler does all the
work. It prints two indenting spaces for every level of ancestor
elements, then it prints the element and attribute
information. Finally it increments the global Depth
variable.
d167 2
a168 1
d188 1
d190 3
a192 3
The end tag simply does the bookkeeping work of decrementing
Depth.
d198 1
d201 1
a201 1
shoveling the document to the parser so that it can do its work.
d203 7
a209 8
The Expat distribution comes as a compressed (with GNU gzip) tar
file. You may download the latest version from Source Forge. After
unpacking this, cd into the directory. Then follow either the Win32
directions or Unix directions below.
d212 4
d217 2
a218 8
If you're using the GNU compiler under cygwin, follow the Unix
directions in the next section. Otherwise if you have Microsoft's
Developer Studio installed, then from Windows Explorer double-click on
"expat.dsp" in the lib directory and build and install in the usual
manner.
Alternatively, you may download the Win32 binary package that
contains the "expat.h" include file and a pre-built DLL.
d221 2
a222 3
First you'll need to run the configure shell script in order to
configure the Makefiles and headers for your system.
d225 2
a226 2
and you have permission on your system to install into /usr/local, you
can install Expat with this sequence of commands:
d228 1
a228 1
d235 4
a238 11
only one we'll mention here is the --prefix option. You
can find out all the options available by running configure with just
the --help option.
By default, the configure script sets things up so that the library
gets installed in /usr/local/lib and the associated
header file in /usr/local/include. But if you were to
give the option, --prefix=/home/me/mystuff, then the
library and header would get installed in
/home/me/mystuff/lib and
/home/me/mystuff/include respectively.
d240 10
a249 1
d251 13
d265 2
a266 17
Compiling and Linking Against Expat
Unless you installed Expat in a location not expected by your
compiler and linker, all you have to do to use Expat in your programs
is to include the Expat header (#include <expat.h>)
in your files that make calls to it and to tell the linker that it
needs to link against the Expat library. On Unix systems, this would
usually be done with the -lexpat argument. Otherwise,
you'll need to tell the compiler where to look for the Expat header
and the linker where to find the Expat library. You may also need to
take steps to tell the operating system where to find this libary at
run time.
On a Unix-based system, here's what a Makefile might look like when
Expat is installed in a standard location:
d273 1
d275 1
a275 1
If you installed Expat in, say, /home/me/mystuff, then
d278 2
a279 1
d287 1
d289 5
a293 5
You'd also have to set the environment variable
LD_LIBRARY_PATH to /home/me/mystuff/lib (or
to ${LD_LIBRARY_PATH}:/home/me/mystuff/lib if
LD_LIBRARY_PATH already has some directories in it) in order to run
your application.
d296 16
a311 15
As we saw in the example in the overview, the first step in parsing
an XML document with Expat is to create a parser object. There are three functions in the Expat API for creating a
parser object. However, only two of these (XML_ParserCreate and XML_ParserCreateNS) can be used for
constructing a parser for a top-level document. The object returned
by these functions is an opaque pointer (i.e. "expat.h" declares it as
void *) to data with further internal structure. In order to free the
memory associated with this object you must call XML_ParserFree. Note that if you have
provided any user data that gets stored in the
parser, then your application is responsible for freeing it prior to
calling XML_ParserFree.
d314 26
a339 28
parsing only one XML document or external parsed entity. If your
application needs to parse many XML documents, then it needs to create
a parser object for each one. The best way to deal with this is to
create a higher level object that contains all the default
initialization you want for your parser objects.
Walking through a document hierarchy with a stream oriented parser
will require a good stack mechanism in order to keep track of current
context. For instance, to answer the simple question, "What element
does this text belong to?" requires a stack, since the parser may have
descended into other elements that are children of the current one and
has encountered this text on the way out.
The things you're likely to want to keep on a stack are the
currently opened element and it's attributes. You push this
information onto the stack in the start handler and you pop it off in
the end handler.
For some tasks, it is sufficient to just keep information on what
the depth of the stack is (or would be if you had one.) The outline
program shown above presents one example. Another such task would be
skipping over a complete element. When you see the start tag for the
element you want to skip, you set a skip flag and record the depth at
which the element started. When the end tag handler encounters the
same depth, the skipped element has ended and the flag may be
cleared. If you follow the convention that the root element starts at
1, then you can use the same variable for skip flag and skip
depth.
d341 2
a342 1
d377 1
d379 1
d381 8
a388 9
Notice in the above example the difference in how depth is
manipulated in the start and end handlers. The end tag handler should
be the mirror image of the start tag handler. This is necessary to
properly model containment. Since, in the start tag handler, we
incremented depth after the main body of start tag code, then
in the end handler, we need to manipulate it before the main
body. If we'd decided to increment it first thing in the start
handler, then we'd have had to decrement it last thing in the end
handler.
d390 1
a390 1
Communicating between handlers
d394 4
a397 44
the shared variables. You can then tell Expat (with the XML_SetUserData function) to pass a
pointer to this structure to the handlers. This is typically the first
argument received by most handlers.
XML Version
Expat is an XML 1.0 parser, and as such never complains based on
the value of the version pseudo-attribute in the XML
declaration, if present.
If an application needs to check the version number (to support
alternate processing), it should use the XML_SetXmlDeclHandler function to
set a handler that uses the information in the XML declaration to
determine what to do. This example shows how to check that only a
version number of "1.0" is accepted:
static int wrong_version;
static XML_Parser parser;
static void
xmldecl_handler(void *userData,
const XML_Char *version,
const XML_Char *encoding,
int standalone)
{
static const XML_Char Version_1_0[] = {'1', '.', '0', 0};
int i;
for (i = 0; i < (sizeof(Version_1_0) / sizeof(Version_1_0[0])); ++i) {
if (version[i] != Version_1_0[i]) {
wrong_version = 1;
/* also clear all other handlers: */
XML_SetCharacterDataHandler(parser, NULL);
...
return;
}
}
...
}
d401 3
a403 4
When the parser is created using the XML_ParserCreateNS, function, Expat
performs namespace processing. Under namespace processing, Expat
consumes xmlns and xmlns:... attributes,
d405 42
a446 39
occur. This means that your start handler will not see these
attributes. Your application can still be informed of these
declarations by setting namespace declaration handlers with XML_SetNamespaceDeclHandler.
Element type and attribute names that belong to a given namespace
are passed to the appropriate handler in expanded form. By default
this expanded form is a concatenation of the namespace URI, the
separator character (which is the 2nd argument to XML_ParserCreateNS), and the local
name (i.e. the part after the colon). Names with undeclared prefixes
are passed through to the handlers unchanged, with the prefix and
colon still attached. Unprefixed attribute names are never expanded,
and unprefixed element names are only expanded when they are in the
scope of a default namespace.
However if XML_SetReturnNSTriplet has been called with a non-zero
do_nst parameter, then the expanded form for names with
an explicit prefix is a concatenation of: URI, separator, local name,
separator, prefix.
You can set handlers for the start of a namespace declaration and
for the end of a scope of a declaration with the XML_SetNamespaceDeclHandler
function. The StartNamespaceDeclHandler is called prior to the start
tag handler and the EndNamespaceDeclHandler is called before the
corresponding end tag that ends the namespace's scope. The namespace
start handler gets passed the prefix and URI for the namespace. For a
default namespace declaration (xmlns='...'), the prefix will be null.
The URI will be null for the case where the default namespace is being
unset. The namespace end handler just gets the prefix for the closing
scope.
These handlers are called for each declaration. So if, for
instance, a start tag had three namespace declarations, then the
StartNamespaceDeclHandler would be called three times before the start
tag handler is called, once for each declaration.
d450 4
a453 5
While XML is based on Unicode, and every XML processor is required
to recognized UTF-8 and UTF-16 (1 and 2 byte encodings of Unicode),
other encodings may be declared in XML documents or entities. For the
main document, an XML declaration may contain an encoding
declaration:
d459 1
a459 1
looks like an XML declaration with just an encoding declaration:
d464 3
a466 4
With Expat, you may also specify an encoding at the time of
creating a parser. This is useful when the encoding information may
come from a source outside the document itself (like a higher level
protocol.)
d468 1
a468 2
There are four built-in encodings
in Expat:
d470 4
a473 4
UTF-8
UTF-16
ISO-8859-1
US-ASCII
d480 10
a489 10
structure. Your handler must fill in this structure and return
XML_STATUS_OK if it knows how to deal with the
encoding. Otherwise the handler should return
XML_STATUS_ERROR. The handler also gets passed a pointer
to an optional application data structure that you may indicate when
you set the handler.
Expat places restrictions on character encodings that it can
support by filling in the XML_Encoding structure.
include file:
d502 14
a515 16
XML_Encoding contains an array of integers that
correspond to the 1st byte of an encoding sequence. If the value in
the array for a byte is zero or positive, then the byte is a single
byte encoding that encodes the Unicode scalar value contained in the
array. A -1 in this array indicates a malformed byte. If the value is
-2, -3, or -4, then the byte is the beginning of a 2, 3, or 4 byte
sequence respectively. Multi-byte sequences are sent to the convert
function pointed at in the XML_Encoding structure. This
function should return the Unicode scalar value for the sequence or -1
if the sequence is malformed.
One pitfall that novice Expat users are likely to fall into is that
although Expat may accept input in various encodings, the strings that
it passes to the handlers are always encoded in UTF-8 or UTF-16
(depending on how Expat was compiled). Your application is responsible
for any translation of these strings into other encodings.
d519 16
a534 16
Expat does not read or parse external entities directly. Note that
any external DTD is a special case of an external entity. If you've
set no ExternalEntityRefHandler, then external entity
references are silently ignored. Otherwise, it calls your handler with
the information needed to read and parse the external entity.
Your handler isn't actually responsible for parsing the entity, but
it is responsible for creating a subsidiary parser with XML_ExternalEntityParserCreate that will do the job. This
returns an instance of XML_Parser that has handlers and
other data structures initialized from the parent parser. You may then
use XML_Parse or XML_ParseBuffer calls against this
parser. Since external entities my refer to other external entities,
your handler should be prepared to be called recursively.
d537 3
a539 5
In order to parse parameter entities, before starting the parse,
you must call XML_SetParamEntityParsing with one of the following
arguments:
d550 2
a551 2
In order to read an external DTD, you also have to set an external
entity reference handler as described above.
d604 8
a611 1
the namespace URI and the local part of the name.
d614 1
a614 1
d618 2
a619 2
const XML_Char *encoding);
d621 7
a627 7
Construct a new XML_Parser object for parsing an external
general entity. Context is the context argument passed in a call to a
ExternalEntityRefHandler. Other state information such as handlers,
user data, namespace processing is inherited from the parser passed as
the 1st argument. So you shouldn't need to call any of the behavior
changing functions on this parser (unless you want it to act
differently than the parent parser).
d630 1
a630 1
d632 2
a633 2
XML_ParserFree(XML_Parser p);
d636 1
a636 16
freeing any memory associated with user data.
XML_Bool
XML_ParserReset(XML_Parser p);
Clean up the memory structures maintained by the parser so that it may
be used again. After this has been called, parser is
ready to start parsing a new document. This function may not be used
on a parser created using XML_ExternalEntityParserCreate; it will return XML_FALSE in that case. Returns
XML_TRUE on success. Your application is responsible for
dealing with any memory associated with user data.
a640 10
To state the obvious: the three parsing functions XML_Parse, XML_ParseBuffer and >XML_GetBuffer must not be
called from within a handler unless they operate on a separate parser
instance, that is, one that did not call the handler. For example, it
is OK to call the parsing functions from within an
XML_ExternalEntityRefHandler, if they apply to the parser
created by XML_ExternalEntityParserCreate.
d659 2
a660 2
If a parse error occurred, it returns XML_STATUS_ERROR.
Otherwise it returns XML_STATUS_OK value.
d663 2
a664 2
XML_Status
d667 2
a668 2
int isFinal);
d670 3
a672 5
This is just like XML_Parse,
except in this case Expat provides the buffer. By obtaining the
buffer from Expat with the XML_GetBuffer function, the application can avoid double
copying of the input.
d675 1
a675 1
d678 2
a679 2
int len);
d682 1
a682 1
into. A NULL value is returned if Expat can't allocate enough memory for
d684 1
a684 2
XML_ParseBuffer. A
typical use would look like this:
d686 2
a687 1
d696 1
a696 1
if (bytes_read < 0) {
d706 1
a706 1
}
d709 1
a711 1
d717 1
a717 1
is seen, and unset it for the corresponding end tag.
d721 1
a721 1
a return value.
d724 4
a727 4
XML_Char. This type is defined in expat.h as char
* and contains bytes encoding UTF-8. Note that you'll receive
them in this form independent of the original encoding of the
document.
d730 1
a730 1
d733 2
a734 2
d739 1
a739 1
d750 1
a750 1
d753 2
a754 2
d758 1
a758 1
d764 1
a764 1
d768 1
a768 1
d773 1
a773 1
d776 2
a777 2
d782 1
a782 1
d784 1
a784 1
is NOT nul-terminated. You have to use the length argument
d792 1
a792 1
d795 2
a796 2
d802 1
a802 1
d809 1
a809 1
d812 2
a813 2
d817 1
a817 1
d823 1
a823 1
d826 2
a827 2
d830 1
a830 1
d835 1
a835 1
d838 2
a839 2
d842 1
a842 1
d847 1
a847 1
d851 1
a851 1
d856 1
a856 1
d859 2
a860 2
d865 1
a865 2
d867 5
a871 9
otherwise be handled. This includes both data for which no handlers
can be set (like some kinds of DTD declarations) and data which could
be reported but which currently has no handler set. The characters
are passed exactly as they were present in the XML document except
that they will be encoded in UTF-8 or UTF-16. Line boundaries are not
normalized. Note that a byte order mark character is not passed to the
default handler. There are no guarantees about how characters are
divided between calls to the default handler: for example, a comment
might be split between multiple calls. Setting the handler with
a874 3
This sets a default handler, but doesn't inhibit the expansion of
internal entity references. The entity reference will not be passed
to the default handler.
The context parameter specifies the parsing context in
the format expected by the context argument to XML_ExternalEntityParserCreate. code is
valid only until the handler returns, so if the referenced entity is
to be parsed later, it must be copied. context is NULL
only when the entity is a parameter entity, which is how one can
differentiate between general and parameter entities.
The base parameter is the base to use for relative
system identifiers. It is set by XML_SetBase and may be NULL. The
publicId parameter is the public id given in the entity
declaration and may be NULL. systemId is the system
identifier specified in the entity declaration and is never NULL.
There are a couple of ways in which this handler differs from
others. First, this handler returns a status indicator (an
integer). XML_STATUS_OK should be returned for successful
handling of the external entity reference. Returning
XML_STATUS_ERROR indicates failure, and causes the
calling parser to return an
XML_ERROR_EXTERNAL_ENTITY_HANDLING error.
Second, instead of having the user data as its first argument, it
receives the parser that encountered the entity reference. This, along
with the context parameter, may be used as arguments to a call to
XML_ExternalEntityParserCreate. Using the returned
parser, the body of the external entity can be recursively parsed.
Set the argument passed to the ExternalEntityRefHandler. If
arg is not NULL, it is the new value passed to the
handler set using XML_SetExternalEntityRefHandler; if arg is
NULL, the argument passed to the handler function will be the parser
object itself.
Note:
The type of arg and the type of the first argument to the
ExternalEntityRefHandler do not match. This function takes a
void * to be passed to the handler, while the handler
accepts an XML_Parser. This is a historical accident,
but will not be corrected before Expat 2.0 (at the earliest) to avoid
causing compiler warnings for code that's known to work with this
API. It is the responsibility of the application code to know the
actual type of the argument passed to the handler and to manage it
properly.
typedef void
(*XML_SkippedEntityHandler)(void *userData,
const XML_Char *entityName,
int is_parameter_entity);
Set a skipped entity handler. This is called in two situations:
An entity reference is encountered for which no declaration
has been read and this is not an error.
An internal entity reference is read, but not expanded, because
XML_SetDefaultHandler
has been called.
The is_parameter_entity argument will be non-zero for
a parameter entity and zero for a general entity.
Note: skipped
parameter entities in declarations and skipped general entities in
attribute values cannot be reported, because the event would be out of
sync with the reporting of the declarations or attribute values
Set a handler to deal with encodings other than the built in set. This should be done before
XML_Parse or XML_ParseBuffer have been called on the
given parser.
If the handler knows how to deal with an encoding
with the given name, it should fill in the info data
structure and return XML_STATUS_ERROR. Otherwise it
should return XML_STATUS_OK. The handler will be called
at most once per parsed (external) entity. The optional application
data pointer encodingHandlerData will be passed back to
the handler.
d969 2
a970 3
function is the data pointer from XML_Encoding. The
string s is NOT nul-terminated and points at the sequence of
bytes to be converted.
d972 2
a973 2
The function pointed at by release is called by the
parser when it is finished with the encoding. It may be NULL.
d977 1
a977 1
d980 2
a981 2
d986 1
a986 1
a990 6
Note:
Due to limitations of the implementation, the
StartNamespaceDeclHandler is not called unless the StartElementHandler
is also set. The specific value of the StartElementHandler is allowed
to change freely, so long as it is not NULL.
d994 1
a994 1
d997 2
a998 2
d1002 1
a1002 1
d1004 3
a1006 9
declaration. This will be called, for each namespace declaration,
after the handler for the end tag of the element in which the
namespace was declared.
Note:
Due to limitations of the implementation, the EndNamespaceDeclHandler
is not called unless the StartElementHandler is also set. The
specific value of the StartElementHandler is allowed to change freely,
so long as it is not NULL.
d1010 1
a1010 1
d1014 2
a1015 9
Sets both namespace declaration handlers with a single call.
Note:
Due to limitations of the implementation, the
StartNamespaceDeclHandler and EndNamespaceDeclHandler are not called
unless the StartElementHandler is also set. The specific value of the
StartElementHandler is allowed to change freely, so long as it is not
NULL.
d1019 1
a1019 1
d1022 2
a1023 2
d1029 1
a1029 1
d1031 6
a1036 7
text declarations discovered in external entities. The way to
distinguish is that the version parameter will be NULL
for text declarations. The encoding parameter may be NULL
for an XML declaration. The standalone argument will
contain -1, 0, or 1 indicating respectively that there was no
standalone parameter in the declaration, that it was given as no, or
that it was given as yes.
d1040 1
a1040 1
d1043 2
a1044 2
d1051 1
a1051 1
d1059 1
a1059 1
d1062 2
a1063 2
d1066 1
a1066 1
d1072 1
a1072 1
d1076 1
a1076 1
d1081 1
a1081 1
d1084 2
a1085 2
d1090 2
a1091 2
d1117 5
a1121 7
Sets a handler for element declarations in a DTD. The handler gets
called with the name of the element in the declaration and a pointer
to a structure that contains the element model. It is the
application's responsibility to free this data structure using
XML_FreeContentModel.
d1126 14
a1139 16
quant will be XML_CQUANT_NONE, and the other
fields will be zero or NULL. If type is
XML_CTYPE_MIXED, then quant will be
XML_CQUANT_NONE or XML_CQUANT_REP and
numchildren will contain the number of elements that are
allowed to be mixed in and children points to an array of
XML_Content structures that will all have type
XML_CTYPE_NAME with no quantification. Only the root node can be type
XML_CTYPE_EMPTY, XML_CTYPE_ANY, or
XML_CTYPE_MIXED.
For type XML_CTYPE_NAME, the name field
points to the name and the numchildren and
children fields will be zero and NULL. The
quant field will indicate any quantifiers placed on the
name.
d1142 3
a1144 3
indicate a choice or sequence respectively. The
numchildren field indicates how many nodes in the choice
or sequence and children points to the nodes.
d1148 1
a1148 1
d1151 2
a1152 2
d1160 9
a1168 9
Set a handler for attlist declarations in the DTD. This handler is
called for each attribute. So a single attlist declaration
with multiple attributes declared will generate multiple calls to this
handler. The elname parameter returns the name of the
element for which the attribute is being declared. The attribute name
is in the attname parameter. The attribute type is in the
att_type parameter. It is the string representing the
type in the declaration with whitespace removed.
d1170 2
a1171 2
The dflt parameter holds the default value. It will be
NULL in the case of "#IMPLIED" or "#REQUIRED" attributes. You can
d1175 3
a1177 2
isrequired, but they will have the non-NULL fixed value
in the dflt parameter.
d1181 1
a1181 1
d1184 2
a1185 2
d1196 1
a1196 1
d1198 3
a1200 3
The is_parameter_entity argument will be non-zero in the
case of parameter entities and zero otherwise.
d1204 6
a1209 7
The value string is not NULL terminated; the length is
provided in the value_length parameter. Do not use
value_length to test for internal entities, since it is
legal to have zero-length values. Instead check for whether or not
value is NULL.
The notationName
argument will have a non-NULL value only for unparsed entity
declarations.
d1213 1
a1213 1
d1216 2
a1217 2
d1225 1
a1225 1
d1232 4
a1235 3
This handler is obsolete and is provided for backwards
compatibility. Use instead XML_SetEntityDeclHandler.
d1239 1
a1239 1
d1242 2
a1243 2
d1250 1
a1250 1
d1255 1
a1255 1
d1258 2
a1259 2
d1262 1
a1262 1
d1264 4
a1267 5
This happens when there is an external subset or a reference to a
parameter entity, but does not have standalone set to "yes" in an XML
declaration. If this handler returns XML_STATUS_ERROR,
then the parser will throw an XML_ERROR_NOT_STANDALONE
error.
d1271 9
d1281 1
a1281 13
These are the functions you'll want to call when the parse
functions return XML_STATUS_ERROR (a parse error has
ocurred), although the position reporting functions are useful outside
of errors. The position reported is the byte position (in the original
document or entity encoding) of the first of the sequence of
characters that generated the current event (or the error that caused
the parse functions to return XML_STATUS_ERROR.)
The position reporting functions are accurate only outside of the
DTD. In other words, they usually return bogus information when
called from within a DTD declaration handler.
d1329 2
a1330 5
Return the number of bytes in the current event. Returns
0 if the event is inside a reference to an internal
entity and for the end-tag event for empty element tags (the later can
be used to distinguish empty-element tags from empty elements using
separate start and end tags).
d1333 1
a1333 1
d1338 1
a1338 1
a1339 1
d1342 2
a1343 3
parse position, and set the integer pointed at by size to
the size of the returned buffer.
d1346 5
a1350 6
the handler that made the call. This input buffer contains the
untranslated bytes of the input.
Only a limited amount of context is kept, so if the event
triggering a call spans over a very large amount of input, the actual
parse position may be before the beginning of the buffer.
d1354 2
d1357 1
a1357 4
The functions in this section either obtain state information from
the parser or can be used to dynamicly set parser options.
d1360 2
a1361 2
void *userData);
d1363 2
a1364 2
This sets the user data pointer that gets passed to handlers. It
overwrites any previous value for this pointer. Note that the
d1366 3
a1368 3
userData when it is finished with the parser. So if you
call this when there's already a pointer there, and you haven't freed
the memory associated with it, then you've probably just leaked
d1372 1
a1372 1
d1386 3
a1388 4
After this is called, handlers receive the parser in their
userData arguments. The user data can still be obtained
using the XML_GetUserData function.
d1391 2
a1392 2
d1397 3
a1399 4
Set the base to be used for resolving relative URIs in system
identifiers. The return value is XML_STATUS_ERROR if
there's no memory to store base, otherwise it's
XML_STATUS_OK.
d1402 1
a1402 1
d1418 5
a1422 6
ATTLIST declaration. This function returns the number of attributes
that were explicitly set times two, thus giving the offset in the
atts array passed to the start tag handler of the first
attribute set due to defaults. It supplies information for the last
call to a start handler. If called inside a start handler, then that
means the current call.
d1425 1
a1425 1
d1428 1
a1428 1
d1430 3
a1432 5
Returns the index of the ID attribute passed in the atts array in the
last call to XML_StartElementHandler, or -1 if there is no ID
attribute. If called inside a start handler, then that means the
current call.
d1435 2
a1436 2
d1443 2
a1444 5
It must not be called after XML_Parse or XML_ParseBuffer have been called on the given parser.
Returns XML_STATUS_OK on success or
XML_STATUS_ERROR on error.
d1447 1
a1447 1
This function allows an application to provide an external subset
for the document type declaration for documents which do not specify
an external subset of their own. For documents which specify an
external subset in their DOCTYPE declaration, the application-provided
subset will be ignored. If the document does not contain a DOCTYPE
declaration at all and useDTD is true, the
application-provided subset will be parsed, but the
startDoctypeDeclHandler and
endDoctypeDeclHandler functions, if set, will not be
called. The setting of parameter entity parsing, controlled using
XML_SetParamEntityParsing, will be honored.
The application-provided external subset is read by calling the
external entity reference handler set via XML_SetExternalEntityRefHandler with both
publicId and systemId set to NULL.
If this function is called after parsing has begun, it returns
XML_ERROR_CANT_CHANGE_FEATURE_ONCE_PARSING and ignores
useDTD. If called when Expat has been compiled without
DTD support, it returns
XML_ERROR_FEATURE_REQUIRES_XML_DTD. Otherwise, it
returns XML_ERROR_NONE.
d1468 1
a1468 1
d1472 10
a1481 12
XML_ParserCreateNS,
i.e. when namespace processing is in effect. The do_nst
sets whether or not prefixes are returned with names qualified with a
namespace prefix. If this function is called with do_nst
non-zero, then afterwards namespace qualified names (that is qualified
with a prefix as opposed to belonging to a default namespace) are
returned as a triplet with the three parts separated by the namespace
separator specified when the parser was created. The order of
returned parts is URI, local name, and prefix.
If
do_nst is zero, then namespaces are reported in the
default manner, URI then local_name separated by the namespace
separator.
d1484 1
a1484 15
void
XML_DefaultCurrent(XML_Parser parser);
This can be called within a handler for a start element, end element,
processing instruction or character data. It causes the corresponding
markup to be passed to the default handler set by XML_SetDefaultHandler or
XML_SetDefaultHandlerExpand. It does nothing if there is
not a default handler.
d1487 1
a1487 1
d1489 1
a1489 1
Return the library version as a string (e.g. "expat_1.95.1").
d1492 2
a1493 2
struct XML_Expat_Version
d1495 4
a1498 2
d1504 1
a1504 3
Return the library version information as a structure.
a1514 57
Returns a list of "feature" records, providing details on how
Expat was configured at compile time. Most applications should not
need to worry about this, but this information is otherwise not
available from Expat. This function allows code that does need to
check these features to do so at runtime.
The return value is an array of XML_Feature,
terminated by a record with a feature of
XML_FEATURE_END and name of NULL,
identifying the feature-test macros Expat was compiled with. Since an
application that requires this kind of information needs to determine
the type of character the name points to, records for the
XML_FEATURE_SIZEOF_XML_CHAR and
XML_FEATURE_SIZEOF_XML_LCHAR will be located at the
beginning of the list, followed by XML_FEATURE_UNICODE
and XML_FEATURE_UNICODE_WCHAR_T, if they are present at
all.
Some features have an associated value. If there isn't an
associated value, the value field is set to 0. At this
time, the following features have been defined to have values:
XML_FEATURE_SIZEOF_XML_CHAR
The number of bytes occupied by one XML_Char
character.
XML_FEATURE_SIZEOF_XML_LCHAR
The number of bytes occupied by one XML_LChar
character.
XML_FEATURE_CONTEXT_BYTES
The maximum number of characters of context which can be
reported by XML_GetInputContext.
Function to deallocate the model argument passed to the
XML_ElementDeclHandler callback set using XML_ElementDeclHandler.
This function should not be used for any other purpose.
The following functions allow external code to share the memory
allocator an XML_Parser has been configured to use. This
is especially useful for third-party libraries that interact with a
parser object created by application code, or heavily layered
applications. This can be essential when using dynamically loaded
libraries which use different C standard libraries (this can happen on
Windows, at least).
Allocate size bytes of memory using the allocator the
parser object has been configured to use. Returns a
pointer to the memory or NULL on failure. Memory allocated in this
way must be freed using XML_MemFree.
Allocate size bytes of memory using the allocator the
parser object has been configured to use.
ptr must point to a block of memory allocated by XML_MemMalloc or
XML_MemRealloc, or be NULL. This function tries to
expand the block pointed to by ptr if possible. Returns
a pointer to the memory or NULL on failure. On success, the original
block has either been expanded or freed. On failure, the original
block has not been freed; the caller is responsible for freeing the
original block. Memory allocated in this way must be freed using
XML_MemFree.
void
XML_MemFree(XML_Parser parser, void *ptr);
Free a block of memory pointed to by ptr. The block must
have been allocated by XML_MemMalloc or XML_MemRealloc, or be NULL.
