Indeed, there are 58 authors so tracking them down would be a task in
itself! I wonder how many different generator programs have been used?
Only a few. My best estimate is about five, but I haven't checked the repositories to be certain. It's a small concern, but something to keep in mind.
We certainly don't have to contact all the authors. As long as the text of the SRFIs doesn't change, the APIs won't change, so we can make the changes without bothering the authors.
I think the bottom line is that no matter what metadata format we come
up with, it will be impossible to generate it from some of the programs
the authors used. So if we demand a very high rate of compatibility then
our project is dead in the water.
Generation of the HTML is not part of the SRFI process. Authors are required to provide HTML directly. Some, however, include their source, e.g. in Markdown or some Scheme-based format, in the repository when they submit their SRFIs. That makes it convenient for them to update their HTML documents later, and it may give inspiration for tools that the rest of us might like. I'm okay if what we do breaks some authors' tools, but I'd like us to try to minimize that. So a very high rate of compatibility is not necessary, but I just don't want to forget.
Could the maintenance problem be solved with a social contract instead
of a technical one? We could say that authors are free to submit their
SRFI in the lenient HTML format they've been using until now. But once
it's published, maintainers are free to make changes to the HTML markup
that don't alter the text of the SRFI. Kind SRFI writers could polish
the markup themselves to save maintainers the trouble, but it probably
wouldn't be a huge burden for an experienced maintainer to fix the
markup at the rate new SRFIs are published. We could have several
volunteers do this and there is no time pressure on it since the
leniently formatted SRFIs would still be readable.
Yes, that sounds okay to me. I still think we can use HTML parsers instead of requiring strict XHTML parsing, though. That seems to be the way that the field has been moving in any case, starting even before HTML 5.
I am all in favor of having more volunteers! Unless the conversion is automated, I would prefer not to do it all myself.