On 05.03.2019 18.44, Arthur A. Gleckler wrote:

> Note that some authors write their documents in another markup language,
> then convert them to HTML.  This proposal would require that they update
> their software to produce the new classes, or edit the generated HTML
> afterwards.  That shouldn't stop us from trying this proposal, but it's
> something to keep in mind.

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?

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.

> One requirement I have for any proposal is that the effort required by
> an author to comply is minimal.  Part of the reason that the SRFI
> process has been successful for twenty years is that the editors have
> kept "friction" low.
This sounds wise.

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.

Lassi