Also, it's very important that any work along these lines results
in something with "guidelines" in its title, and not "standard."
Anybody contemplating (or currently working on) such a format,
please remember this. If you take the simple step of using the
word "guidelines," I guarantee you'll get few or none of these
knee-jerk "keep yer paws off my FAQ list" reactions that
proposals incorporating the word "standard" routinely receive
>from me and many other FAQ list maintainers.
Come to think of it, the fact that a proposal for a standard
format has come up again (and is likely to keep doing so)
suggests that Jon might want to put explicit language in one of
the news.answers meta-FAQ's along the lines of:
There is explicitly and deliberately NO STANDARD for the
form, formatting, or presentation of the content (body)
of periodic informational postings. This lack is neither
accidental, nor the result of an as-yet-incomplete
attempt at formulating such a standard -- any standard
would do more harm than good, by alienating volunteer FAQ
list maintainers, creating more work for them, and
constraining their options. Please do not make the
mistake of assuming that the lack of an FAQ list
formatting standard is a void that needs filling.
That may be too verbose, but my point is that we should document
somewhere that we have decided not to decide; that the only
standard is that there is no standard.
> 2) don't even try to please everyone. pick something that will please
> most, implement it.
In particular, don't try to please the people who want to do
fancy automated postprocessing. Any "format" which is supposed
to be both human- and machine-readable will always be suboptimal.
The right way to allow fancy postprocessing is with a fully
machine-readable format, and we certainly don't need any more of
those; something like HTML is probably already more than
adequate. If FAQ list maintainers want to encourage
postprocessing and fancier searching, let them distribute two
versions of their lists, one human-readable, the other machine-
readable. (This is what I plan to do.) Those maintainers
(probably most of them) who do *not* want to distribute two
versions can continue to distribute only a human-readable one,
and the people who insist on hypertext and pretty-printing can
just sit on their thumbs.
(Alternately, it would probably be possible to maintain only an
HTML version -- HTML to plain text converters already exist.)
> OK-- my main suggestion is that it seems to me that FAQs are trying to
> be many things to many people. I would recommend a universal faq format
> UFF. This can be turned into gopher or URL or straight ASCII documents
> with conversion tools.
This is essentially what I plan to do, but note that any such
"universal FAQ format" would be inherently and entirely
voluntary, and hence not nearly universal. It would be an
implementation detail, a tool used by maintainers who chose to
use it to streamline their ability to create distributable FAQ
lists in the desired formats: plain text, HTML, texinfo,
whatever.
Before I can distribute an HTML version of the comp.lang.c FAQ
list (which, as I've mentioned, I'd like to do), I'll be defining
my own little format which could be what L. is calling "UFF."
I won't collaborate with anybody while defining it, that would
just delay the task even further. When I'm done, it'll do what I
need; if other people can use it, great; but if they can't,
because it doesn't have or isn't extensible enough to handle
some features that they need, it'll be no skin off my teeth.
I won't propose or promote it as any kind of standard, but if
people want to use it, and its associated tools, it'll be there.
Steve Summit
scs@eskimo.com
[
Usenet Hypertext FAQ Archive |
Search Mail Archive |
Authors |
Usenet
]
[
1993 |
1994 |
1995 |
1996 |
1997
]
© Copyright The Landfield Group, 1997
All rights reserved