Hello, thank you for your work in all these years, and also thank you for recently having pulled a merge-request of mine regarding the relax ng parser. About this specific topic, I noticed that since 2.14 you began stating that the relax ng code is in bad shape. I agree with you that the code has some quirks. The issues I personally found with the code were:
- The event based validation seems to not report all errors, some are lost in the process (example described in my MR, not fixed by it)
- There’s no efficient way to disable production of errors/warnings. A flag could be added so in case of errors/warnings the message is not produced/allocated at all. Now it will be always fed to the user registered callback or the default one that prints to standard error
- The streaming validation could not be reset in case of errors, something that I actually fixed with my MR
- The streaming validation seems to be arbitrarily limited to deterministic schemas at element level. IMO, this is theoretically not strictly required and it could be “relaxed”
- Loading some schemas that are not that big is very slow. There may be an inefficiency/missing caching that hopefully is not that hard to fix
So said, the code doesn’t look that terrible to me, even if certainly it has a steep learning curve. The code has also some objective qualities: it’s really self contained and it’s around 10k lines of code, which is not that much. While I don’t want to influence the next maintainer in a non collaborative way, I recommend against deprecating the relax ng validation code as it will be relevant in the future because of explicit mentions in PDF related specifications such as ISO 19005-4:2020, or ISO 16684-2:2014, as I mentioned here. I kindly ask you if you can better state what you found bad in the code, and how you think it should be improved (maybe you pointed it out already somewhere but I am a newcomer, sorry).