As the original author and architect of Xerces C++, I'm probably to blame for
everything :-) Though, as mentioned, this was like 1998'ish, and a lot of spilt
milk has passed under the bridge since then. Oh, to be able to go back and
spill it again, and this time have my stock options vest BEFORE the bubble
popped. Oh well...
Anyhoo. IMO, C++ itself is a twilight language, much less this particular C++
project. It's time to move on just in more general terms. I've moved on to Rust
unless I'm being paid to do otherwise. And will probably shortly here do a
Rusty XML parser implementation for a personal project I'm working on. It'll be
an order of magnitude safer and significantly simpler.
I also did a C++ XML parser/DTD validator for my CIDLib C++ system, roughly
based on my original Xerces work. It's much nicer just because it's part of a
comprehensive framework, but considerably less feature rich. And it's not
something you can just pull out and use separately because it is part of a
comprehensive C++ framework that doesn't use the STL or any third party
libraries. And, to be fair, it's not 'modern' C++ either, in that it's pretty
light on the use of templates.
https://github.com/DeanRoddey/CIDLib
That's always the gotcha with C++. It's impossible to do a really, fully
integrated, comphrensive system without dumping the STL and all its UB and
evolutionary baggage. (and by extension all the third party stuff built on top
of it.) But, if you do that, no one will use it. I spent decades on my system
and no one cared in the slightest.
Dean Roddey
Chairman/CTO
Charmed Quark Systems, Ltd
www.charmedquark.com
-Original Message-
From: Roger Leigh [mailto:rle...@codelibre.net]
Sent: Friday, October 7, 2022 8:00 AM
To: c-dev@xerces.apache.org
Subject: RE: Prepping a 3.2.4 release
Dear all,
We had a similar conversation to this on the Xalan mailing list a few months
back:
https://lists.apache.org/list?d...@xalan.apache.org:2022-6 (Future of Xalan-C)
https://lists.apache.org/list?d...@xalan.apache.org:2022-7 (Retire Xalan to the
Attic) [Xalan-J]
In both cases there was no definitive decision, but if you take the time to
read through the first thread it provides some overview of the historical
contributions to the project and the past and current maintainers. The bottom
line is this: there are no maintainers, haven't been for over a decade.. I'm
stopping the small effort I made, and the previous people involved have moved
onto Saxon, and no longer use it. The project, while notionally functional, is
not maintained, and it has no future unless people step up with real commitment
to do the necessary work. No real work has been done on the project since 2005
other than two point releases incorporating small bugfixes. It's dead, and
it's been dead for a long time now. I will revisit this and try to get a
conclusion, and while any decision made for Xerces-C++ will also affect Xalan
immediately, it should retired in any case.
For Xalan-J, this actually spurred someone into action, and some work is
currently being done. However, it remains to be seen if this is sufficient to
revive the project--a short term burst of activity does not mean the project is
healthy for the longer term.
For Xerces-C++, I think we're in a very similar situation to Xalan-C. We have
sporadic maintenance work by Scott and myself, and recently we've had Even
Rouault provide fixes based upon static analysis to fix some longstanding
issues. But other than that, we don't have much activity. I do think we need
to be honest with our users about the true status of this project. If it's not
maintained, we should consider moving it to the Attic. I personally think that
would be the correct course of action. I don't think we should be encouraging
new use of Xerces-C++ if it's an unmaintained project with a legacy codebase,
it's doing them a disservice to pretend that it's viable and well supported,
which it is not.
I originally used Xerces+Xalan for XML and XSLT processing in C++. As Boris
said, they are the only game in town. But that doesn't necessarily mean they
are a sensible choice or the right choice. I only joined the project because I
was struggling so much to incorporate them into a modern C++11 (now C++14)
codebase. It's really painful:
* It predates adoption of Standard C++ (98)
* It doesn't use standard exception types
* It doesn't use conventional memory allocation strategies
* It doesn't use conventional character types
* Memory management is a pain, which is exacerbated by the need to do so much
manual string conversions (e.g. UTF-8 to UTF-16 and vice versa).
* The build system was problematic on modern platforms
A lot of the work I've done is to gradually address some of these. Like
allowing char16_t as XMLCh. And adding CMake support. Clang support and fixes
to work with modern compilers. And adding support for other standard library
features
