>>> Personally, I'm pleased with the way this format turned out and would >>> consider it almost done for publication. > > @Lassi I don't know what is your intended timeline for this project, > but I would take a more "thorough" approach... I would say that > before we actually submit something for "ratification", we take our > time to experiment, design, and implement the required tools. I have to have the same timeline as everyone else since this is a group effort :) I was just saying that the S-expression format has basically all the information I'd like to have, and also supports everything Arthur is tracking (well, we could add "see also" entries). I don't have any further experiments to do so I'm done when you're done. It seems that the HTML structure requires more thought, though again we have basically exhausted the practical options. (It's either the current HTML with some added classes, or your clean XHTML. I guess the decision would rest on how much time it takes for a volunteer to convert to the XHTML since we can't require all authors to submit SRFIs in it.) I believe the HTML format is the only thing that will have implications for future SRFI authors, so that would be the only thing that has to be finalized in a "formal" manner (i.e. once we're done, we'd formally announce requirements and suggestions for the new submission format). I think the S-expression format and tool development can be more laid back since they affect fewer people -- mostly Arthur and us for now :) I wouldn't worry about a formal release or publication of these. We could make one experimental repo with the new S-expression files. I could update the <http://schemedoc.herokuapp.com/> API to use them and Arthur could make versions of his personal scripts related to running the SRFI process and website. Once the S-expression format is reasonably stable so we can use it ourselves, we could push those files into the official repo of each SRFI. Then we could make an announcement. But once again this would not affect or disrupt the SRFI process, just people making tools (currently just us). The tools could have their own repo (or be in that same repo). We could start with the personal tools we have now and gradually combine them into an official tool written in Scheme. That tool would eventually cross-validate the SRFI HTML and the metadata files to check that they have the same information (as far as applicable). > I say this, because if we are to "modify" anything in the SRFI > process, I think it should be done only once (else it would lose > credibility and traction). Thus we should have everything > "integrated" before we start going through old SRFI documents and > propose the new process. I definitely agree that the HTML format shouldn't be announced formally until we are reasonably sure we have got it right. But I wouldn't stress about the S-expressions and tools, as above. > Therefore the "devil is in the details"... Just saying that "a place > would be held in the format" is not enough, as these SRFI's > cross-reference each-other. > As said above, at least for me, my time is quite limited on this > project and it would take some while for me to go through my > "experiment". It would be great to have consistent types across all the SRFIs but it sounds like that would take a lot more time to get correct than the rest of the things we intend to do. Therefore I would suggest a formal announcement just for the HTML structure. The types could remain in continuous development as long as needed, and live in their own S-expression files which continue to be updated as progress is made. > I also propose that this experimental process should be > done in the open, perhaps on this mailing list if there are no > objections. I think this has turned out to be a good place for discussion so far :)
