Xerces-C++ defines a numeric preprocessor macro, _XERCES_VERSION, for users to introduce into their code to perform conditional compilation where the version of Xerces-C++ is detected in order to enable or disable version specific capabilities. For example,

	#if _XERCES_VERSION >= 30102 // Code specific to Xerces-C++ version 3.1.2 and later. #else // Old code. #endif

The minor and revision (patch level) numbers have two digits of resolution which means that '1' becomes '01' and '2' becomes '02' in this example.

There are also other string macros or constants to represent the Xerces-C++ version. Please refer to the xercesc/util/XercesVersion.hpp header for details.

Xerces-C++ contains an implementation of the W3C XML Schema Language. See the XML Schema Support page for details.

In addition to using the parse() method to parse an XML File. You can use the other two parsing methods, parseFirst() and parseNext() to do the so called progressive parsing. This way you don't have to depend on throwing an exception to terminate the parsing operation.

Calling parseFirst() will cause the DTD (both internal and external subsets), and any pre-content, i.e. everything up to but not including the root element, to be parsed. Subsequent calls to parseNext() will cause one more pieces of markup to be parsed, and propagated from the core scanning code to the parser (and hence either on to you if using SAX/SAX2 or into the DOM tree if using DOM).

You can quit the parse any time by just not calling parseNext() anymore and breaking out of the loop. When you call parseNext() and the end of the root element is the next piece of markup, the parser will continue on to the end of the file and return false, to let you know that the parse is done. So a typical progressive parse loop will look like this:

	// Create a progressive scan token XMLPScanToken token; if (!parser.parseFirst(xmlFile, token)) { cerr << "scanFirst() failed\n" << endl; return 1; } // // We started ok, so lets call scanNext() // until we find what we want or hit the end. // bool gotMore = true; while (gotMore && !handler.getDone()) gotMore = parser.parseNext(token);

In this case, our event handler object (named 'handler') is watching for some criteria and will return a status from its getDone() method. Since the handler sees the SAX events coming out of the SAXParser, it can tell when it finds what it wants. So we loop until we get no more data or our handler indicates that it saw what it wanted to see.

When doing non-progressive parses, the parser can easily know when the parse is complete and insure that any used resources are cleaned up. Even in the case of a fatal parsing error, it can clean up all per-parse resources. However, when progressive parsing is done, the client code doing the parse loop might choose to stop the parse before the end of the primary file is reached. In such cases, the parser will not know that the parse has ended, so any resources will not be reclaimed until the parser is destroyed or another parse is started.

This might not seem like such a bad thing; however, in this case, the files and sockets which were opened in order to parse the referenced XML entities will remain open. This could cause serious problems. Therefore, you should destroy the parser instance in such cases, or restart another parse immediately. In a future release, a reset method will be provided to do this more cleanly.

Also note that you must create a scan token and pass it back in on each call. This insures that things don't get done out of sequence. When you call parseFirst() or parse(), any previous scan tokens are invalidated and will cause an error if used again. This prevents incorrect mixed use of the two different parsing schemes or incorrect calls to parseNext().

Xerces-C++ provides a function to pre-parse the grammar so that users can check for any syntax error before using the grammar. Users can also optionally cache these pre-parsed grammars for later use during actual parsing.

Here is an example:

	XercesDOMParser parser; // Enable schema processing. parser.setDoSchema(true); parser.setDONamespaces(true); // Let's preparse the schema grammar (.xsd) and cache it. Grammar* grammar = parser.loadGrammar(xmlFile, Grammar::SchemaGrammarType, true);

Besides caching pre-parsed schema grammars, users can also cache any grammars encountered during an xml document parse.

Here is an example:

	SAXParser parser; // Enable grammar caching by setting cacheGrammarFromParse to true. // The parser will cache any encountered grammars if it does not // exist in the pool. // If the grammar is DTD, no internal subset is allowed. parser.cacheGrammarFromParse(true); // Let's parse our xml file (DTD grammar) parser.parse(xmlFile); // We can get the grammar where the root element was declared // by calling the parser's method getRootGrammar; // Note: The parser owns the grammar, and the user should not delete it. Grammar* grammar = parser.getRootGrammar();

We can use any previously cached grammars when parsing new xml documents. Here are some examples on how to use those cached grammars:

	/** * Caching and reusing XML Schema (.xsd) grammar * Parse an XML document and cache its grammar set. Then, use the cached * grammar set in subsequent parses. */ XercesDOMParser parser; // Enable schema processing parser.setDoSchema(true); parser.setDoNamespaces(true); // Enable grammar caching parser.cacheGrammarFromParse(true); // Let's parse the XML document. The parser will cache any grammars encountered. parser.parse(xmlFile); // No need to enable re-use by setting useCachedGrammarInParse to true. It is // automatically enabled with grammar caching. for (int i=0; i< 3; i++) parser.parse(xmlFile); // This will flush the grammar pool parser.resetCachedGrammarPool();

	/** * Caching and reusing DTD grammar * Preparse a grammar and cache it in the pool. Then, we use the cached grammar * when parsing XML documents. */ SAX2XMLReader* parser = XMLReaderFactory::createXMLReader(); // Load grammar and cache it parser->loadGrammar(dtdFile, Grammar::DTDGrammarType, true); // enable grammar reuse parser->setFeature(XMLUni::fgXercesUseCachedGrammarInParse, true); // Parse xml files parser->parse(xmlFile1); parser->parse(xmlFile2);

There are some limitations about caching and using cached grammars:

• When caching/reusing DTD grammars, no internal subset is allowed.
• When preparsing grammars with caching option enabled, if a grammar, in the result set, already exists in the pool (same namespace for schema or same system id for DTD), the entire set will not be cached. This behavior is the default but can be overridden for XML Schema caching. See the SAX/SAX2/DOM parser features for details.
• When parsing an XML document with the grammar caching option enabled, the reuse option is also automatically enabled. We will only parse a grammar if it does not exist in the pool.

The Xerces-C++ supports loadable message text. Although the current distribution only supports English, it is capable of supporting other languages. Anyone interested in contributing any translations should contact us. This would be an extremely useful service.

In order to support the local message loading services, all the error messages are captured in an XML file in the src/xercesc/NLS/ directory. There is a simple program, in the tools/NLS/Xlat/ directory, which can translate that text in various formats. It currently supports a simple 'in memory' format (i.e. an array of strings), the Win32 resource format, and the message catalog format. The 'in memory' format is intended for very simple installations or for use when porting to a new platform (since you can use it until you can get your own local message loading support done.)

In the src/xercesc/util/ directory, there is an XMLMsgLoader class. This is an abstraction from which any number of message loading services can be derived. Your platform driver file can create whichever type of message loader it wants to use on that platform. Xerces-C++ currently has versions for the in memory format, the Win32 resource format, the message catalog format, and ICU message loader. Some of the platforms can support multiple message loaders, in which case a #define token is used to control which one is used. You can set this in your build projects to control the message loader type used.

Xerces-C++ also supports pluggable transcoding services. The XMLTransService class is an abstract API that can be derived from, to support any desired transcoding service. XMLTranscoder is the abstract API for a particular instance of a transcoder for a particular encoding. The platform driver file decides what specific type of transcoder to use, which allows each platform to use its native transcoding services, or the ICU service if desired.

Implementations are provided for Win32 native services, ICU services, and the iconv services available on many Unix platforms. The Win32 version only provides native code page services, so it can only handle XML code in the intrinsic encodings ASCII, UTF-8, UTF-16 (Big/Small Endian), UCS4 (Big/Small Endian), EBCDIC code pages IBM037, IBM1047 and IBM1140 encodings, ISO-8859-1 (aka Latin1) and Windows-1252. The ICU version provides all of the encodings that ICU supports. The iconv version will support the encodings supported by the local system. You can use transcoders we provide or create your own if you feel ours are insufficient in some way, or if your platform requires an implementation that Xerces-C++ does not provide.

All platform dependent code in Xerces-C++ has been isolated to a couple of files, which should ease the porting effort. The src/xercesc/util directory contains all such files. In particular:

• The src/xercesc/util/FileManagers directory contains implementations of file managers for various platforms.
• The src/xercesc/util/MutexManagers directory contains implementations of mutex managers for various platforms.
• The src/xercesc/util/Xerces_autoconf_const* files provide base definitions for various platforms.

Other concerns are:

• Does ICU compile on your platform? If not, then you'll need to create a transcoder implementation that uses your local transcoding services. The iconv transcoder should work for you, though perhaps with some modifications.
• What message loader will you use? To get started, you can use the "in memory" one, which is very simple and easy. Then, once you get going, you may want to adapt the message catalog message loader, or write one of your own that uses local services.
• What should I define XMLCh to be? Please refer to What should I define XMLCh to be? for further details.

Finally, you need to decide about how to define XMLCh. Generally, XMLCh should be defined to be a type suitable for holding a utf-16 encoded (16 bit) value, usually an unsigned short.

All XML data is handled within Xerces-C++ as strings of XMLCh characters. Regardless of the size of the type chosen, the data stored in variables of type XMLCh will always be utf-16 encoded values.

Unlike XMLCh, the encoding of wchar_t is platform dependent. Sometimes it is utf-16 (AIX, Windows), sometimes ucs-4 (Solaris, Linux), sometimes it is not based on Unicode at all (HP/UX, AS/400, system 390).

Some earlier releases of Xerces-C++ defined XMLCh to be the same type as wchar_t on most platforms, with the goal of making it possible to pass XMLCh strings to library or system functions that were expecting wchar_t parameters. This approach has been abandoned because of

• Portability problems with any code that assumes that the types of XMLCh and wchar_t are compatible
• Excessive memory usage, especially in the DOM, on platforms with 32 bit wchar_t.
• utf-16 encoded XMLCh is not always compatible with ucs-4 encoded wchar_t on Solaris and Linux. The problem occurs with Unicode characters with values greater than 64k; in ucs-4 the value is stored as a single 32 bit quantity. With utf-16, the value will be stored as a "surrogate pair" of two 16 bit values. Even with XMLCh equated to wchar_t, xerces will still create the utf-16 encoded surrogate pairs, which are illegal in ucs-4 encoded wchar_t strings.

Xerces-C++ makes use of C++ namespace to make sure its definitions do not conflict with other libraries and applications. As a result applications must namespace-qualify all Xerces-C++ classes, data and variables using the xercesc name. Alternatively, applications can use using xercesc::<Name>; declarations to make individual Xerces-C++ names visible in the current scope or using namespace xercesc; definition to make all Xerces-C++ names visible in the current scope.

While the above information should be sufficient for the majority of applications, for cases where several versions of the Xerces-C++ library must be used in the same application, namespace versioning is provided. The following convenience macros can be used to access the Xerces-C++ namespace names with versions embedded (see src/xercesc/util/XercesDefs.hpp):

	#define XERCES_CPP_NAMESPACE_BEGIN namespace xercesc_3_3 { #define XERCES_CPP_NAMESPACE_END } #define XERCES_CPP_NAMESPACE_USE using namespace xercesc_3_3; #define XERCES_CPP_NAMESPACE_QUALIFIER xercesc_3_3:: namespace xercesc_3_3 { } namespace xercesc = xercesc_3_3;

Xerces-C++ provides mechanisms for Native Language Support (NLS). Even though the current distribution has only English message file, it is capable of supporting other languages once the translated version of the target language is available.

An application can specify the locale for the message loader in their very first invocation to XMLPlatformUtils::Initialize() by supplying a parameter for the target locale intended. The default locale is "en_US".

	// Initialize the parser system try { XMLPlatformUtils::Initialize("fr_FR"); } catch () { }

Xerces-C++ searches for message files at the location specified in the XERCESC_NLS_HOME environment variable and, if that is not set, at the default message directory, $XERCESCROOT/msg.

Application can specify an alternative location for the message files in their very first invocation to XMLPlatformUtils::Initialize() by supplying a parameter for the alternative location.

	// Initialize the parser system try { XMLPlatformUtils::Initialize("en_US", "/usr/nls"); } catch () { }

Xerces-C++ reports panic conditions encountered to the panic handler installed. The panic handler can take whatever action appropriate to handle the panic condition.

Xerces-C++ allows application to provide a customized panic handler (class implementing the interface PanicHandler), in its very first invocation of XMLPlatformUtils::Initialize().

In the absence of an application-specific panic handler, Xerces-C++ default panic handler is installed and used, which aborts program whenever a panic condition is encountered.

	// Initialize the parser system try { PanicHandler* ph = new MyPanicHandler(); XMLPlatformUtils::Initialize("en_US", "/usr/nls", ph); } catch () { }

Certain applications wish to maintain precise control over memory allocation. This enables them to recover more easily from crashes of individual components, as well as to allocate memory more efficiently than a general-purpose OS-level procedure with no knowledge of the characteristics of the program making the requests for memory. In Xerces-C++ this is supported via the Pluggable Memory Handler.

Users who wish to implement their own MemoryManager, an interface found in xercesc/framework/MemoryManager.hpp, need to implement only two methods:

	// This method allocates requested memory. // the parameter is the requested memory size // A pointer to the allocated memory is returned. virtual void* allocate(XMLSize_t size) = 0; // This method deallocates memory // The parameter is a pointer to the allocated memory to be deleted virtual void deallocate(void* p) = 0;

To maximize the amount of flexibility that applications have in terms of controlling memory allocation, a MemoryManager instance may be set as part of the call to XMLPlatformUtils::Initialize() to allow for static initialization to be done with the given MemoryHandler; a (possibly different) MemoryManager may be passed in to the constructors of all Xerces parser objects as well, and all dynamic allocations within the parsers will make use of this object. Assuming that MyMemoryHandler is a class that implements the MemoryManager interface, here is a bit of pseudocode which illustrates these ideas:

	MyMemoryHandler *mm_for_statics = new MyMemoryHandler(); MyMemoryHandler *mm_for_particular_parser = new MyMemoryManager(); // initialize the parser information; try/catch // removed for brevity XMLPlatformUtils::Initialize(XMLUni::fgXercescDefaultLocale, 0,0, mm_for_statics); // create a parser object XercesDOMParser *parser = new XercesDomParser(mm_for_particular_parser); // ... delete parser; XMLPlatformUtils::Terminate();

If a user provides a MemoryManager object to the parser, then the user owns that object. It is also important to note that Xerces-C++ default implementation simply uses the global new and delete operators.

The purpose of the SecurityManager class is to permit applications a means to have the parser reject documents whose processing would otherwise consume large amounts of system resources. Malicious use of such documents could be used to launch a denial-of-service attack against a system running the parser. Initially, the SecurityManager only knows about attacks that can result from exponential entity expansion; this is the only known attack that involves processing a single XML document. Other, similar attacks can be launched if arbitrary schemas may be parsed; there already exist means (via use of the EntityResolver interface) by which applications can deny processing of untrusted schemas. In future, the SecurityManager will be expanded to take these other exploits into account.

The SecurityManager class is very simple: It will contain getters and setters corresponding to each known variety of exploit. These will reflect limits that the application may impose on the parser with respect to the processing of various XML constructs. When an instance of SecurityManager is instantiated, default values for these limits will be provided that should suit most applications.

By default, Xerces-C++ is a wholly conformant XML parser; that is, no security-related considerations will be observed by default. An application must provide an instance of the SecurityManager class to a parser in order to make that parser behave in a security-conscious manner. For example:

	SAXParser *myParser = new SAXParser(); SecurityManager *myManager = new SecurityManager(); myManager->setEntityExpansionLimit(100000); // larger than default myParser->setSecurityManager(myManager); // ... use the parser

Note that SecurityManager instances may be set on all kinds of Xerces-C++ parsers; please see the documentation for the individual parsers for details.

Note also that the application always owns the SecurityManager instance. The default SecurityManager that Xerces-C++ provides is not thread-safe; although it only uses primitive operations at the moment, users may need to extend the class with a thread-safe implementation on some platforms.

For performance and modularity Xerces-C++ provides a mechanism for specifying the scanner to be used when scanning an XML document. Such mechanism will enable the creation of special purpose scanners that can be easily plugged in.

Xerces-C++ supports the following scanners:

WFXMLScanner

The WFXMLScanner is a non-validating scanner which performs well-formedness check only. It does not do any DTD/XMLSchema processing. If the XML document contains a DOCTYPE, it will be silently ignored (i.e. no warning message is issued). Similarly, any schema specific attributes (e.g. schemaLocation), will be treated as normal element attributes. Setting grammar specific features/properties will have no effect on its behavior (e.g. setLoadExternalDTD(true) is ignored). // Create a DOM parser XercesDOMParser parser; // Specify scanner name parser.useScanner(XMLUni::fgWFXMLScanner); // Specify other parser features, e.g. parser.setDoNamespaces(true);

DGXMLScanner

The DGXMLScanner handles XML documents with DOCTYPE information. It does not do any XMLSchema processing, which means that any schema specific attributes (e.g. schemaLocation), will be treated as normal element attributes. Setting schema grammar specific features/properties will have no effect on its behavior (e.g. setDoSchema(true) and setLoadSchema(true) are ignored). // Create a SAX parser SAXParser parser; // Specify scanner name parser.useScanner(XMLUni::fgDGXMLScanner); // Specify other parser features, e.g. parser.setLoadExternalDTD(true);

SGXMLScanner

The SGXMLScanner handles XML documents with XML schema grammar information. If the XML document contains a DOCTYPE, it will be ignored. Namespace and schema processing features are on by default, and setting them to off has not effect. // Create a SAX2 parser SAX2XMLReader* parser = XMLReaderFactory::createXMLReader(); // Specify scanner name parser->setProperty(XMLUni::fgXercesScannerName, (void *)XMLUni::fgSGXMLScanner); // Specify other parser features, e.g. parser->setFeature(XMLUni::fgXercesSchemaFullChecking, false);

IGXMLScanner

The IGXMLScanner is an integrated scanner and handles XML documents with DTD and/or XML schema grammar. This is the default scanner used by the various parsers if no scanner is specified. // Create a DOMLSParser parser DOMLSParser *parser = ((DOMImplementationLS*)impl)->createLSParser( DOMImplementationLS::MODE_SYNCHRONOUS, 0); // Specify scanner name - This is optional as IGXMLScanner is the default parser->getDomConfig()->setParameter( XMLUni::fgXercesScannerName, (void *)XMLUni::fgIGXMLScanner); // Specify other parser features, e.g. parser->getDomConfig()->setParameter(XMLUni::fgDOMNamespaces, doNamespaces); parser->getDomConfig()->setParameter(XMLUni::fgXercesSchema, doSchema);

All Xerces applications that wish to limit a wide range of security risks MUST install appropriate implementations of API-specific "entity/resource resolution" implementations to govern/police the resolution of external entities by the parser.

In the event that an entity resolver wants to delegate the job of resolving a particular resource to the parser, Xerces will automatically handle local file references but will delegate any non-local file URLs to a NetAccessor, a plugin controlled at build time supporting access to remote systems. Most of the built-in implementations are limited, with the principal exception of support for libcurl as an implementation, which supports a wide range of protocols, potentially including http over TLS, which is rarely supported in other cases.

It is incredibly important to implement your own entity resolution code to ensure that if you allow the parser to perform its own resolution, it does so only under conditions and against URLs you trust. The library will NOT your application from the many potential threats arising from arbitrary resource resolution.

Notably, entity/resource resolver implementations can be accompanied by changing the default parser features to disallow "default" resolution, preventing the parser from executing its own NetAccessors to perform these lookups.