Hi Scott,
With regard to the retirement discussion, I just wanted to forward this message on from Even Rouault who was having trouble subscribing and posting to the list: ------------ Hi, I have given a try to 3.2.4rc1 against the GDAL (https://gdal.org / https://github.com/OSGeo/gdal) regression test suite, and everything works like a charm. Regarding the discussion about the possibility of retirement of Xerces-C++, I just want to say that Xerces-C++ has unique features that I'm not aware of in other C/C++ open-source libraries and that we strongly leverage in the above mentioned open-source GDAL project. In one of the drivers of GDAL, the GMLAS one (Geographic Markup Language application Schema - https://gdal.org/drivers/vector/gmlas.html), we use not only Xerces-C++ XML parsing capabilities and XML Schema validation ones, but the driver depends on using XML Schema grammar classes of Xerces-C++ to fully understand the XML schema constructs and derive a whole relational database table structure. In particular we use a lot of the classes at xercesc/framework/psvi/XS*.hpp. This driver is at the core of the https://github.com/BRGM/gml_application_schema_toolbox plugin for the QGIS open source project. Even if the XML tech is less trendy those years, it is still used in a number of contexts of sharing of information with geographic content in various application fields: EU Inspire GML (https://inspire.ec.europa.eu/document-tags/data-specifications), geological data (http://geosciml.org/), etc. So we'd for sure like seeing Xerces-C++ existence to go on, even in a minimal maintenance mode. Best regards, Even ------------ And one bit extra from myself. For anyone who isn't following the Xalan-C mailing list, the outcome from the vote on the lists was to retire Xalan-C and move it to the Attic. https://lists.apache.org/thread/oj90kfd9ckt57yw1tthxlryylhjgrwsj is the relevant thread. Regards, Roger > -----Original Message----- > From: Cantor, Scott <canto...@osu.edu> > Sent: 05 October 2022 21:56 > To: c-dev@xerces.apache.org > Subject: Re: Prepping a 3.2.4 release > > > I'm afraid that due to other commitments, I've been unable to do > > any further work on the master branch for 4.0.0, and it's unlikely > > that this will change in the near future. If anything, I'm unlikely > > to be able to spend much more time on the project at all, and I might > > have to end my involvement entirely. > > That isn't surprising, but I appreciate the forewarning. That's why I didn't > really favor trying to do a 4.0.0 originally, I just don't think there's > enough > long term resource commitment for that to be a wise choice. > > Were it my decision, I would post a warning that the code is being sunsetted > and anybody on it should be getting off it. Which I think is pretty clear as > it is, > but it's the responsible and proper thing to just say so. > > > We do have a large accumulation of patches which would certainly be > > worth carrying over to the 3.2 branch where applicable, > > Yes, that's my goal right now, within reason. I simply can't "fix" most things > unfortunately because I don't know the code and the risk of breaking things > is much higher than the payoff in most cases. > > > When it comes to ABI compatibility checking, I'll be happy to do runs > > of some of the ABI checking tools to look for any compatibility issues > > with the ABI or API, if you haven't already done this. > > My approach, as we've been debating, is just to avoid the possibility > whereever I can by not touching headers, but I am willing to accept that I'm > much more conservative about this than I should be and things may not > work quite the way I've always thought they did. > > > It would be nice to get the CI fixed up again before making a > > release. It's probably not too difficult to get working again; the CI > > image and the build logic probably need updating to cope with external > > changes which broke it in the interim. I can try to find a bit of > > time to inspect this--it's not too difficult, just takes time to wait for > > builds > for each change to test it. > > I definitely can't spend time there, so if you can, that's great. If not, > it's best > to wind down anything I can't support unless somebody else steps up to take > it over. > > Thanks for checking in. > > -- Scott > > > B > KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > KKKKCB [ X ܚX KK[XZ[ > > Y] ][ X ܚX P \ \˘\X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ > > Y] Z[ \ \˘\X K ܙ B
