There are some major architectural changes between the 2.3.x and &XercesCName; 1.4.0 releases of the parser, and as a result the code has undergone significant restructuring. The list below mentions the public api's which existed in 2.3.x and no longer exist in &XercesCName; 1.4.0. It also mentions the &XercesCName; 1.4.0 api which will give you the same functionality. Note: This list is not exhaustive. The API docs (and ultimately the header files) supplement this information.

• parsers/[Non]Validating[DOM/SAX]parser.hpp
  These files/classes have all been consolidated in the new version to just two files/classes: [DOM/SAX]Parser.hpp. Validation is now a property which may be set before invoking the parse. Now, the setDoValidation() method controls the validation processing.
• The framework/XMLDocumentTypeHandler.hpp been replaced with validators/DTD/DocTypeHandler.hpp.
• The following methods now have different set of parameters because the underlying base class methods have changed in the 3.x release. These methods belong to one of XMLDocumentHandler, XMLErrorReporter or DocTypeHandler interfaces.
• [Non]Validating[DOM/SAX]Parser::docComment
• [Non]Validating[DOM/SAX]Parser::doctypePI
• [Non]ValidatingSAXParser::elementDecl
• [Non]ValidatingSAXParser::endAttList
• [Non]ValidatingSAXParser::entityDecl
• [Non]ValidatingSAXParser::notationDecl
• [Non]ValidatingSAXParser::startAttList
• [Non]ValidatingSAXParser::TextDecl
• [Non]ValidatingSAXParser::docComment
• [Non]ValidatingSAXParser::docPI
• [Non]Validating[DOM/SAX]Parser::endElement
• [Non]Validating[DOM/SAX]Parser::startElement
• [Non]Validating[DOM/SAX]Parser::XMLDecl
• [Non]Validating[DOM/SAX]Parser::error
• The following methods/data members changed visibility from protected in 2.3.x to private (with public setters and getters, as appropriate).
• [Non]ValidatingDOMParser::fDocument
• [Non]ValidatingDOMParser::fCurrentParent
• [Non]ValidatingDOMParser::fCurrentNode
• [Non]ValidatingDOMParser::fNodeStack
• The following files have moved, possibly requiring changes in the #include statements.
• MemBufInputSource.hpp
• StdInInputSource.hpp
• URLInputSource.hpp
• All the DTD validator code was moved from internal to separate validators/DTD directory.
• The error code definitions which were earlier in internal/ErrorCodes.hpp are now split up into the following files:
• framework/XMLErrorCodes.hpp - Core XML errors
• framework/XMLValidityCodes.hpp - DTD validity errors
• util/XMLExceptMsgs.hpp - C++ specific exception codes.

The sample programs no longer use any of the unsupported util/xxx classes. They only existed to allow us to write portable samples. But, since we feel that the wide character APIs are supported on a lot of platforms these days, it was decided to go ahead and just write the samples in terms of these. If your system does not support these APIs, you will not be able to build and run the samples. On some platforms, these APIs might perhaps be optional packages or require runtime updates or some such action.

More samples have been added as well. These highlight some of the new functionality introduced in the new code base. And the existing ones have been cleaned up as well.

The new samples are:

1. PParse - Demonstrates 'progressive parse' (see below)
2. StdInParse - Demonstrates use of the standard in input source
3. EnumVal - Shows how to enumerate the markup decls in a DTD Validator

In the XML4C 2.x code base, there were the following parser classes (in the src/parsers/ source directory): NonValidatingSAXParser, ValidatingSAXParser, NonValidatingDOMParser, ValidatingDOMParser. The non-validating ones were the base classes and the validating ones just derived from them and turned on the validation. This was deemed a little bit overblown, considering the tiny amount of code required to turn on validation and the fact that it makes people use a pointer to the parser in most cases (if they needed to support either validating or non-validating versions.)

The new code base just has SAXParer and DOMParser classes. These are capable of handling both validating and non-validating modes, according to the state of a flag that you can set on them. For instance, here is a code snippet that shows this in action.

We feel that this is a simpler architecture, and that it makes things easier for you. In the above example, for instance, the parser will be cleaned up for you automatically upon exit since you don't have to allocate it anymore.

Some of the classes previously in the src/internal/ directory have been moved to their more correct location in the src/framework/ directory. These are classes used by the outside world and should have been framework classes to begin with. Also, to avoid name classes in the absence of C++ namespace support, some of these clashes have been renamed to make them more XML specific and less likely to clash. More classes might end up being moved to framework as well.

So you might have to change a few include statements to find these classes in their new locations. And you might have to rename some of the names of the classes, if you used any of the ones whose names were changed.

The src/util directory was becoming somewhat of a dumping ground of platform and compiler stuff. So we reworked that directory to better spread things out. The new scheme is:

This organization makes things much easier to understand. And it makes it easier to find which files you need and which are optional. Note that only per-platform files have any hard coded references to specific message loaders or transcoders. So if you don't include the ICU implementations of these services, you don't need to link in ICU or use any ICU headers. The rest of the system works only in terms of the abstraction APIs.