From owner-freebsd-doc Fri May 24 00:28:41 1996 Return-Path: owner-doc Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA05449 for doc-outgoing; Fri, 24 May 1996 00:28:41 -0700 (PDT) Received: from Fieber-John.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA05444 for ; Fri, 24 May 1996 00:28:39 -0700 (PDT) Received: from localhost (jfieber@localhost) by Fieber-John.campusview.indiana.edu (8.7.5/8.7.3) with SMTP id CAA01400; Fri, 24 May 1996 02:28:34 -0500 (EST) X-Authentication-Warning: Fieber-John.campusview.indiana.edu: jfieber owned process doing -bs Date: Fri, 24 May 1996 02:28:34 -0500 (EST) From: John Fieber X-Sender: jfieber@Fieber-John.campusview.indiana.edu To: Francisco Reyes cc: FreeBSD doc Mailing list Subject: Re: Hardware compatibility documentation In-Reply-To: <199605240445.EAA203934@pop01.ny.us.ibm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-doc@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 24 May 1996, Francisco Reyes wrote: > SGML is not database friendly. !! I'll make you eat that statement. :-) You have it exactly backward. SGML is *far* better suited for representing and manipulating structured data than any traditional database I've ever met. Of course, for an application this small, it probably doesn't matter much. > Once we have an ASCII file with one entry > per item then writing a program to convert that to SGML is > a one shot deal. The other advantage of this approach is that > we can easily change the format if the need arised. Again, backwards. Once we have an SGML file then writing a program to convert that to ASCII is a one shot deal. Of course, if you are doing the coding, I'll just shut my mouth and be happy. :-) > I also think that it is better to start collecting the data and then > consider how we want to present it. On the other hand, we need to think about what information we want to present so we know what information to try and collect. I'm not one for blind data collection. Specifically, just collecting a list of hardware isn't very useful. We need to ask precise questions about how that hardware does or doesn't work. A vague question ("Comments?") isn't going to generate very useful responses. Other interesting questions that might be useful to users is knowing what application a given collection of hardware is being used for. If I'm looking for a machine to use as a heavy duty web server, It would be nice if I could look and see what sort of hardware setups people are using in that setting. There are a bazillion questions we can ask, but nobody will answer a bazillion so we have to trim it down to a few carefully selected ones. (oh, and just to jab a bit more, your one line database probably won't handle the essay questions so well :-) > Where do we go from here? > Let's get this started! Agreed! A simple place is to design some www forms for collecting the basic hardware information and a cgi script to pack it into a file or mail message. In the meantime we can ponder what other information we would like to get, then add that to the forms. -john == jfieber@indiana.edu =========================================== == http://fallout.campusview.indiana.edu/~jfieber ================