Our production Xerces version is (and has been, for quite a while) 1.5.2, released in October of 2001. On occasion, but not recently, I've built several of our XML-using packages against 1.6.0. Everything had to be recompiled and relinked against the newer version, but otherwise the procedure was painless. Last week Alex installed 1.7.0 on SLAC Linux so I could try it out. So far we have made no changes to XMLEXT in CVS; the only way to get to the new Xerces is to modify your own local copy of XMLEXT.
Even 1.7.0 is relatively old. It was released in March of 2002. Since then versions 2.0.0, 2.1.0 and 2.2.0 have been released. Converting to any of these versions would require either substantial changes to our code or continued use of deprecated and undocumented (in these versions) classes. There was a substantial internal and partly external reorganization in 2.0.0. If we made use of the new classes we would probably see better performance.
Starting with 1.6.0, Xerces supports XML schema (a way to describe the elements of a particular XML "language", such as our geometry description) fully. One significant advantage of XML schema over DTD's, the method we've used to date, is the ability within schema to better constrain values so that, for example, you can say the only allowed value in a particular context is an integer between 0 and 17. This could be useful (because it would eliminate the need for a lot of error-handling in C++ code) in creating XML descriptions for various calibration types or for the parameter facility. It's less interesting for geometry description since the code is already written.
1.7.0 doesn't have any new features of interest to us, but it does have some bug fixes since 1.6.0, some of which may affect us. 1.7.0 also has a somewhat nicer (because less likely to collide with other libraries) arrangement of include files. Building against 1.7.0 is almost as painless as building against 1.6.0
The "nicer" arrangement is in fact incompatible with our current source since the path to Xerces include files has changed. However, there is a simple work-around: modify XMLEXT to add two items to the include path:
include_dirs ${XMLEXT_DIR}/include
include_dirs ${XMLEXT_DIR}/include/xercesc
instead of just the first one. Xerces files referring to each other can use the original path; our source can use the second path. Our source can be changed as convenient to refer to includes in the new way (prefaced by xercesc/). When it's all changed over the extra path can be eliminated from XMLEXT. In the meantime, having changed nothing except XMLEXT requirements, I have built enough of the XML-using packages to be satisfied that no code changes should be necessary.
What about going all the way to 2.2.0? In order to make it work at all we'd have to make changes to XMLEXT similar to the above (to get to the deprecated include files). In order to take advantage of the enhanced performance we would have to make widespread changes to any package using Xerces classes directly. The changes between 1.7.0 and 2.0.0 were on a large enough scale that I would have to spend some time validating the behavior of any version from 2.0.0 on before I could recommend its use. I don't think this is worthwhile until and unless we determine that XML parsing is a performance bottleneck.
Last modified: