> Metadata consumers and processors would be similar executable documentation.
>
> Also, for there are benefits for spelling the metadata format in
> a standard, as opposed to relying on a particular scraper implementation
> to be the standard.

> Human error would still be possible in coding a scraper that scrapes
> unstructured data.  I don't know the details of how they're coded, but
> it's conceivable they could miss some part of the scheme implementation
> which says which srfi's that implementation supports, especially when
> things change over the years.
>
> Such a mistake will be much harder to make when one is consuming
> well documented and standardized metadata, that was explicitly designed
> to give you that information.
>
> It is still possible for humans to make a mistake in populating the
> metadata in the first place, however.  So I see your point.
>
> I guess this is a tradeoff one has to decide on between errors by
> humans in populating and maintaining their scheme's metadata vs
> errors in scrapers as the contents of tar files change.

By all means, it would be much better if the source information was
provided by Scheme implementations' authors in a standard format so we
could have only one scraper. We are only using the tailor-made scrapers
because we don't have anything better :)

> That makes sense to me.  As long as it's structured data, explicitly
> intended to furnish the desired metadata.

+1. Also, unlike many data formats, S-expressions are easy to extend in
the future without making a mess. This is important for long-term evolution.