Email list hosting service & mailing list manager

SRFI-metadata-syncing SRFI? noosphere@xxxxxx (08 Nov 2020 21:50 UTC)
Re: SRFI-metadata-syncing SRFI? Vladimir Nikishkin (09 Nov 2020 01:00 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 09:41 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 16:15 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 16:36 UTC)
(missing)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 20:35 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 20:57 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 21:05 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 23:41 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (10 Nov 2020 07:53 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 23:45 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 20:49 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 21:11 UTC)
The funnel pattern Lassi Kortela (09 Nov 2020 21:30 UTC)

Re: SRFI-metadata-syncing SRFI? Lassi Kortela 09 Nov 2020 21:11 UTC

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