(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)
(missing)
Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Ciprian Dorin Craciun (06 Mar 2019 17:58 UTC)

Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Ciprian Dorin Craciun 06 Mar 2019 17:58 UTC

On Wed, Mar 6, 2019 at 7:50 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
> > My vote is clear:  Simpler (X)HTML format just indexing and back-referencing.
> > (This could include the name, description and perhaps examples.)
> >
> > Another proposal should cover the heavier syntax meta-data.
>
> OK, we are in pretty fundamental disagreement about what to do here :)
>
> I think we should make a decision about this before starting work on
> anything concrete since it will have a drastic impact on most
> near-future tasks.
>
> My vote is still to have all metadata in the HTML file, but if a
> different decision is made I will co-operate with it.

I think -- as you've pointed before -- that there are multiple types
of meta-data:

(A)  "global" SRFI related meta-data like author, title, identifier
and other "bibliographic" items;
[these in should definitively go into the HTML.]

(B)  "indexing" items, like `<span class="def-prog">make-array</span>`;
[again in the HTML;]

(C)  textual "descriptive" elements related to various definitions
like for examples:
* textual description of a procedure / macro;
* example code snippets;
* test snippets;
[these could be marked inside the HTML, and provide some meta-data;]

(D)  procedure or syntax definition in a way that is machine readable
and from which "signatures" could be extracted;
[and here is where our differences lie;  you want to use HTML to mark
them, and I say it is overkill and should be "moved" to a dedicated
file or section, not necessarily part of the actual SRFI document;]

Therefore I assume that our disagreement is only with (D).

Ciprian.