
























|
 |  |  |  | Migrating to earlier Releases |  |  |  |  |
| |
|
 |  |  |  | Migrating from Xerces-C++ 1.6.0 to 1.7.0 |  |  |  |  |
| |
The following section is a discussion of the technical differences between
Xerces-C++ 1.6.0 code base and the Xerces-C++ 1.7.0 code base.
 |  |  |  | New features in Xerces-C++ 1.7.0 |  |  |  |  |
| |
- Support SAX2-ext's DeclHandler.
- Directory sane_include reorganization: add sub-directory 'xercesc' to src / include folder.
See "Directory change in Xerces-C++ 1.7.0"
below for detail.
- More IDOM test cases - port IDOMMemTest, and merge ThreadTest and IThreadTest.
- Support IconvFBSD in multi-threading environment.
- Use IDOM in schema processing for faster performance.
- Add Project files for BCB6.
- Port to Caldera (SCO) OpenServer.
- Support building with new MacOSURLAccessCF NetAccessor that doesn't require
Carbon but can allow Xerces to live solely within CoreServices layer.
|
 |  |  |  | Directory change in Xerces-C++ 1.7.0 |  |  |  |  |
| |
- A new directory, src/xercesc is created to be the new parent directory of
all src's direct subdirectories.
- And in the binary package, all the headers are distributed in include/xercesc directory.
- Migration considerations:
- Windows application,
either change the include directories setting to
"..\..\..\..\..\src\xercesc" (Projects->settings->C/C++->Preprocessor),
or
change the relevant #include instances in the source/header files, accordingly, eg
#include <util/XMLString.hpp> be changed to
#include <xercesc/util/XMLString.hpp>
- Unix application,
either change the include search path in the Makefile to
" -I <installroot>/include/xercesc",
or
change the relevant #include instances in the source/header files as shown above.
|
 |  |  |  | Public API Changes in Xerces-C++ 1.7.0 |  |  |  |  |
| |
The following lists the public API changes between the Xerces-C++
1.7.0 and the Xerces-C++ 1.7.0 releases
of the parser.
| |
- Added SAX2-ext's DeclHandler class.
See the API documentation page for details.
- To support SAX2-ext's DeclHandler, the following new methods are added
in classes DefaultHandler and SAX2XMLReader:
- void DefaultHandler::elementDecl(const XMLCh* const name, const XMLCh* const model)
- void DefaultHandler::attributeDecl(const XMLCh* const eName, const XMLCh* const aName,
const XMLCh* const type, const XMLCh* const mode, const XMLCh* const value)
- void DefaultHandler::internalEntityDecl(const XMLCh* const name, const XMLCh* const value)
- void DefaultHandler::externalEntityDecl(const XMLCh* const name, const XMLCh* const publicId,
const XMLCh* const systemId)
- DeclHandler* SAX2XMLReader::getDeclarationHandler() const
- void SAX2XMLReader::setDeclarationHandler(DeclHandler* const handler)
- To conform to DOM Level 2 specification, the following methods are added:
- DOM_Node DOM_NodeIterator::getRoot()
- DOM_Node DOM_TreeWalker::getRoot()
- bool DOM_Node::hasAttributes() const
- bool DOM_Element::hasAttribute(const DOMString &name) const
- bool DOM_Element::hasAttributeNS(const DOMString &namespaceURI,
const DOMString &localName) const
- IDOM_Node* IDOM_NodeIterator::getRoot()
- IDOM_Node* IDOM_TreeWalker::getRoot()
- bool IDOM_Node::hasAttributes() const
- bool IDOM_Element::hasAttribute(const XMLCh* name) const
- bool IDOM_Element::hasAttributeNS(const XMLCh* namespaceURI,
const XMLCh* localName) const
- To fix [Bug 5570], a copy constructor is added to DOM_Range
|
| |
- To conform to the SAX2 specification, the namespace-prefixes feature
in SAX2 is set to off as default.
- To fix [Bug 6330], the Base64::encode and Base64::decode have been modified
as follows
- static XMLByte* Base64::encode(const XMLByte* const inputData,
const unsigned int inputLength,
unsigned int* outputLength);
- static XMLByte* Base64::decode(const XMLByte* const inputData,
unsigned int* outputLength);
- static XMLCh* decode(const XMLCh* const inputData,
unsigned int* outputLength);
- To conform to DOM Level 2 specification, the DOM_Node::supports and IDOM_Node::supports
are modified to
- bool DOM_Node::isSupported(const DOMString &feature, const DOMString &version) const
- bool IDOM_Node::isSupported(const XMLCh* feature, const XMLCh* version) const
|
| |
- No Deprecated Public API in this release.
|
|
|
 |  |  |  | Migrating from XML4C 2.x to Xerces-C++ 1.4.0 |  |  |  |  |
| |
The following section is a discussion of the technical differences between
XML4C 2.x code base and the new Xerces-C++ 1.4.0 code base.
| |
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:
- PParse - Demonstrates 'progressive parse' (see below)
- StdInParse - Demonstrates use of the standard in input source
- 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.
 |  |  |  | void ParseThis(const XMLCh* const fileToParse,
const bool validate)
{
//
// Create a SAXParser. It can now just be
// created by value on the stack if we want
// to parse something within this scope.
//
SAXParser myParser;
// Tell it whether to validate or not
myParser.setDoValidation(validate);
// Parse and catch exceptions...
try
{
myParser.parse(fileToParse);
}
...
}; |  |  |  |  |
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.
|
|
|
|