Email list hosting service & mailing list manager

(missing)
(missing)
(missing)
Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Marc Nieper-Wißkirchen (06 Mar 2019 10:12 UTC)
Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Lassi Kortela (06 Mar 2019 19:14 UTC)

Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Lassi Kortela 06 Mar 2019 19:13 UTC

> There's no reason that we can't have both light markup and an external
> file.  If we update srfi-template.html
> <https://srfi.schemers.org/srfi-template.html> with examples of light
> HTML markup, then authors are likely to use that markup.  That will at
> least give us a starting point for providing more detailed information,
> e.g. in a separate file of s-expressions.  Yes, the two files may get
> out of sync, but since SRFIs don't change once they've been finalized
> (except to fix errors), that is unlikely and should be easy to manage.

IMHO this is fine if the two files contain disjoint sets of information.
If the information overlaps, that raises the question of why not just
auto-generate one from the other.

Once again, I think a S-expression file is perfectly fine if it's
auto-generated. Most tools would probably not want to consume the HTML
directly.

I guess the most salient issue right now is procedure argument lists.
The arguments are already listed in the HTML file by necessity; they
would be listed again in the S-expression file. If they are listed twice
in the HTML of some SRFI (first in a summary listing of all defined
procedures, then another time in a detailed exposition), they would be
listed thrice if we add the S-expression file.

Could we come up with the most hairy example of HTML markup possible? As
in, this is the worst it's going to get. Then we would have a data point
to discuss :D Maybe some macro involving optional and rest parameters as
well as quoted parts.