COM wrapper update

["Arnold, Curt" <Cu...@hyprotech.com>]

I just sent Andy Heninger an update to the COM wrapper that will enabling running a slightly hacked version of David Brownell's conformance suite (around 97% conformance) and a significantly hacked
version of the NIST DOM conformance suite (about 50% conformance).  

David Brownell's conformance suite had to be modified to load Xerces.DOMDocument instead of MSXML.DOMDocument and I munged the path names since there was a problem (probably due to a DOM
implementation issue) in finding the base URI for tests in external entities.  I believe all the test failures are due to non-conformance in xerces-c not a problem in the COM wrapper.

The NIST suite had to be modified to change XML data islands to JScript's invoking the Xerces parser, to not crash on HTML DOM tests, add exceptions around some failing calls to allow completion and
to not depend on the doctype being the second child node.  Non-conformance here may be split between improper assumptions in the test suite, problems in the wrapper and problems in xerces-c.

I can make my hacked test suites available for continued development, if anybody wants them.

Whenever, we release xerces-com a few things need to be said about deployment.  Basically, there are three ways xerces-com could be deployed.

1) Deploying a released dll from a Xerces binary distribution

In this case, xerces-com should be installed to a common directory (such as \Program Files\Common Files\Apache\System).  Each release of xerces-com should have a distinct DLL name
(xerces-com-1_2.dll), CLSID's for DOMDocument and XMLHttpRequest, a new version specific ProgID (Xerces.DOMDocument.1.2) and a new type library ID.

This deployment is appropriate for developers, using Xerces with Excel, Windows Scripting or other ad-hoc development.

2) Deploying a corporate custom build

In this case, xerces-com should be installed to a common directory (such as \Program Files\Common Files\MyCompany\System). The DLL should be given different names to prevent your releases from
overwriting each other but they can be the same as a xerces release.  The CLSID's, ProgID's and Typelib ID's MUST be changed to prevent compromising any application that depend on a released DLL.

3) Deploying an application specific build

If you are destributing an application that uses the Xerces COM parser, the safest thing for your app is to create a custom version of the Xerces COM parser and install it in your application
directory.   You MUST change the CLSID's, ProgID's and TypeLib ID's so they do not conflict with the released xerces-com.dll's.