Subject:
|
Re: Format of FAQ items
|
Newsgroups:
|
lugnet.faq
|
Date:
|
Sat, 24 Apr 1999 04:58:44 GMT
|
Viewed:
|
1451 times
|
| |
|
|
In lugnet.faq, jsproat@geocities.com (Sproaticus) writes:
> [...]
> Someone looking for starter questions could probably use the search
> engine, or look at the big huge one-file document (1) and do a text
> search. I would recommend the search engine.
What about an outline format? I made a cool little utility that displays,
in outline format, any sub-tree of the global ng tree...so from any category
sub-homepage you can see what's there beneath it -- especially handy for
things like loc groups and CAD and market and robotics, etc. Maybe that
would be nice for the FAQ too.
> We could make finding starter questions easier by using an "expertise
> level" tag, e.g.:
>
> Subject: Why won't LDraw work?
> Expertise-Level: Beginner
>
> Subject: How do I generate my VEC using shading in LDLite?
> Expertise-Level: Intermediate
>
> Subject: (insert some really obscure parts-authoring question)
> Expertise-Level: Advanced
Hmm, that would work great to limit the scope of the "include." So the
"include" mechanism could, at runtime when the FAQs are created, include
everything matching up through a specified (parameterized) threshold?
Neat-o.
Probably would be safer though to go with simple numeric values instead of
strings and call the header something like Topic-Depth or Topic-Level...
Because while "expertise/beginner/intermediate/advanced" apply well to areas
like .cad and .robotics, they don't make the most sense for areas like
.market or .announce or .admin... Numbers are much easier to manipulate
too...with words, you have to do a hash-lookup on the word and convert it to
a number (which is of course trivial in string-processing languages) but
then you could always have a typo or something.
> > [index/list]
>
> Yes! This, I like a lot. :-,
>
> It has the added benefit of building targeted FAQs (such as a newbie FAQ)
> consisting of items selected from different levels in the heirarchy. I
> give it my blessing.
Hmm. That's a great idea! There's nothing that prevents the index file
from using / or .. characters to pull in whatever funky esoteric stuff it
wants to.
Say, the index file could also snarf up ("include") other sub-FAQs simply by
giving their directory name -- just like you would list a filename. This is
what I did for the ng/category hierarchy index files -- for example the
index file corresponding to /loc/us/wa/ (Washington State) contains the
following list for Seattle, Spokanne, and Tacoma, respectively:
Categories = sea/ spo/ tac/
If I want to make Vancouver show up as part of Washington (not literally,
but as a subcategory of it), I could just add it to the list like this:
Categories = sea/ spo/ tac/ ../../ca/van/
This is a one-way, non-fuzzy relationship, but it's still plenty useful.
> A minor quibble: We should probably use a more machine-friendly date string
> and let it be translated per locale.
OK. What you had originally (19990423) is much better then. Plenty easy to
convert between that and epoch time too, plus it's sortable as an integer.
> A note on tags: Obviously, some tags are necessary. Are *all* tags
> necessary, or would there be places where it's appropriate to not include
> certain tags? For example, if the Location tag can be inferred by the
> item's location in the directory, should it be required?
Good question. No, it probably shouldn't be required. Making it a required
header just means drudgework and more chance for error. In fact, if there
were a way to completely eliminate it altogether, that would be best. The
location of the file in the hierarchy, and the places that it is
included/referred to by other index files, is probably a much better
definition of the places where it belongs. OK, so let's see... Since the
include mechanism is necessary (it's too juicy and useful not to have) and
since the include mechanism can do everything (and more) that the Location
mechanism did, I don't think we need the Location mechanism.
> Similarly, is order important in *all* repeating tags? I guess it is
> in the case of e-mail headers.
Hmm. Hmm. I'll say yes -- order should probably be important/significant
in all repeating tags/headers -- because ignoring the order would make it
more difficult to upgrade the structure to XML months/years down the road.
> 1. I think there should be one, at least for kicks. I've been known to
> print out entire 100+ page FAQs for reading material for trips. It's a
> sign of sickness, I know. :-,
OK, gotcha. Full grokkage on that. I like the threshold thing: let the
user choose which sub-hierarchy to read, and how in-depth it is.
--Todd
|
|
Message has 2 Replies:
 | | Raw FAQ data format (Was: Format of FAQ items)
|
| Todd Lehman (lehman@javanet.com) and Sproaticus (jsproat@geocities.com) writes lots of stuff: Guys! It sounds like you are mixing the raw data format and the presentation format. I'll try to stick to the raw data format here, and list the ideas I (...) (25 years ago, 24-Apr-99, to lugnet.faq)
| | | Re: Format of FAQ items
|
| (...) You mean like a master Table of Contents? Sure, okay. Question" How cautious do we want to get about creeping featuritis? :-, (...) Yep. (...) Oh, yeah. Integers are better for an enumerated value. (...) If you want to write the code for it, (...) (25 years ago, 24-Apr-99, to lugnet.faq)
|
Message is in Reply To:
| | Re: Format of FAQ items
|
| (...) You've convinced me otherwise now. Mea culpa. :-, (...) I think it would take in the whole sub-FAQ. This is (currently) my strategy for giving localized names to the different categories. Someone looking for starter questions could probably (...) (25 years ago, 23-Apr-99, to lugnet.faq)
|
82 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
