Stepping down as libxml2 maintainer

Platform
,
1

I’m stepping down as maintainer of libxml2 which means that this project is more or less unmaintained for now.

I will fix regressions in the 2.15 release until the end of 2025.

28 Likes
2

Thank you for your hard work!

4 Likes
3

Yes, thank you for maintaining libxml2 for such a long time!

5 Likes
4

Hello, since I’ve stepped in as libxslt maintainer I’ve been studying both libxslt and libxml2 codebases. I have the time to maintain the library I just need to get familiar with the latest changes you introduced like:

I haven’t find how to manage both output and input buffers. I found functions like: xmlOutputBufferCreateIO but by the places in which I’ve found them is not clear on how to use them.

Should I send you an email with my questions or do you prefer other means of communication?

10 Likes
5

Thank you Nick for maintaining the key libraries of the internet and used in millions of products globaly. Best of luck to you.

5 Likes
6

I am one of those millions of people that use this library on the behalf of us Thank you very much!!

2 Likes
7

Thanks for your work @nwellnhof!

8

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).

1 Like
9

Thank you for so many years of hard, meticulous work! I always learn something when reading your commits.

10

@nwellnhof a kind reminder, if you find the time to respond to this