Email list hosting service & mailing list manager

(missing)
(missing)
(missing)
Re: Proposal to add HTML class attributes to SRFIs to aid machine-parsing Lassi Kortela (05 Mar 2019 22:47 UTC)
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 05 Mar 2019 22:47 UTC

IMHO it'd be most desirable to have a solution shaped like a funnel:

* Stage 1: Lenient SRFI markup from author
* Stage 2: Lenient SRFI markup with standard classes
* Stage 3: Standard SRFI markup and standard classes

Documents could start from stage 1 or stage 2 and be converted towards
the final stage 3. Either going through stage 2 or direct to stage 3.

Crucially, documents could never travel in the opposite direction. So
once a SRFI's markup has reached stage 2 or 3, we wouldn't support
going back to an earlier stage to make changes - the changes have to
be submitted in a form that preserves the things that are already in
standard form. An editor or volunteer could optionally help the author
with this, but the main thing would be that after we have converted a
document once, the burden of conversion is off our hands.

This would also mean that most tools can simply assume to be reading
stage 3 SRFIs and ignore the earlier stages. A few more tools can deal
also with stage 2 documents. Only a couple special tools would need to
do heuristic conversions of stage 1 to the next stages.

We could *design* these stages in reverse order. So we could start
from the end and design what stage 3 looks like. Stage 2 would then be
designed as a backport of the classes from stage 3, perhaps adding a
few transitional classes if needed. Stage 1 would be what we have now.

Would this approach be possible culturally?

Lassi