| | Working sketch of FAQ item data format
|
|
(Originally in another thread. I gave it its own thread to make finding it and building upon it easier.) Here's a working sketch of the FAQ data format; in quasi-XML, to separate the files. <FILE NAME="file: /faq/lugnet/market/a...1.en.faq"> Refer: (...) (26 years ago, 23-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) What does the Refer header mean? Say, due to what we figured out on the other thread, we can nix the Locations and Newsgroups headers, and just keep the Subject and Author headers. But doesn't the date belong on the same line is the author?... (...) (26 years ago, 24-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) Would "Include" be better? (...) Sure, it looks like you're able to efficiently distinguish between a ng and a non-ng directory. (...) The top line looks good. I doubt we'd need the time-of-day stamp very often, if at all. Would it be possible (...) (26 years ago, 24-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) OK, I grok that better, yes. But why was that file referring to (or including) itself, and why were the other files including files in parent directories rather than subdirectories? For definitions? (I guess you answered this below...) (...) (...) (26 years ago, 25-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
Here's a working sketch of the FAQ data format; the example is wrapped in quasi-XML, to show the file's path. Subject: [the question] Content-Language: [ISO 639 language code] Topic-Level: [integer, 0 is beginner/easy/simple] Revision: [author, ISO (...) (26 years ago, 26-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
Sproaticus: (...) Not really. (...) Both approaches are ok with me. (...) We need a (secondary) resource that translates the Lugnet relative URI's to (more) meaningful text. Aren't "/market/" and "/" implied when you write "/market/auction/"? (...) (...) (26 years ago, 27-Apr-99, to lugnet.faq)
|
|
| | (canceled)
|
|
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) This was my original argument for include. However, Todd already has a mechanism to figure this out on the fly. (...) Not necessarily. There are situations where you don't want to assume association with all parent directories. For example, we (...) (26 years ago, 27-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
Sproaticus: (...) OK, but Todd will have to make these generally available (and translatable). Play well, Jacob ---...--- -- E-mail: sparre@cats.nbi.dk -- -- Web...: <URL:(URL) -- ---...--- (26 years ago, 28-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) Off-the-wall question -- haven't thought about this -- just tossing it out: Would an 'exclude' also be useful in addition to 'include'? (Both are relatively easy to implement.) --Todd (26 years ago, 30-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) At what level would Exclude be in the way? Would you nix all items in the "excluded" file? Would it be selective, allowing certain headers (such as Subject) to remain? What purpose would it serve? Cheers, - jsproat (26 years ago, 30-Apr-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(Originally in another thread. I gave it its own thread to make finding it and building upon it easier. Thanks go to Jacob Sparre Anderseon for tracking these.) These are the headers. All are required unless otherwise specified. None may repeat (...) (26 years ago, 6-May-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) Oh, it was just a thought. I kind of like the simplicity of the robots.txt format. You include and exclude things, and each layer modifies previous layers. Kind of also like the way Unix directory permissions work. One example purpose that an (...) (26 years ago, 6-May-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) What you're talking about sounds more like an inherited directory filter than a header exclude. Hmmm, could this be solved by placing a token file at strategic spots in the directory structure? Cheers, - jsproat (26 years ago, 6-May-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) OK, yes, that's a good way of putting it. I guess I still don't understand what you mean by the include mechanism for headers. I'll have to go back and read the threads more carefully... (...) Maybe; but it wouldn't allow specialized (...) (26 years ago, 7-May-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) Here's a rough sketch: File A has these headers: Flarn: Gook Cheeseball: Snorkle Include: B Include: C File B has these headers: Flarn: Gobbledegook Slack: Snafu Snarf: Quest File C has these headers: Flarn: Vorlon Snarf: Wormy Queen: Keep (...) (26 years ago, 7-May-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) I *think* I'm almost with ya on this... A couple more questions... Is the idea behind this so that lower levels can include headers from upper levels -- headers such as 'Topic-Level'? If so, then do the included headers override what's in the (...) (26 years ago, 7-May-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) Among other things, yes. Upper levels can benefit too, such as bringing in 'Location' headers (1). (...) No; the way I see it, the including file has priority. Fields brought in by an include would be overridden by fields already in the (...) (26 years ago, 7-May-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) Nope (...) Why are 'Location' headers useful again? What do they do (as in an example) that an include mechanism (implicit or explicit or a mix-n-match index) can't do? How terrible is life without the 'Location' header? --Todd (26 years ago, 8-May-99, to lugnet.faq)
|
|
| | Re: Working sketch of FAQ item data format
|
|
(...) Cool. I concur. (...) Um, I think it was for a possible alternative organization scheme, other than placement in a subdirectory. If we use index files instead, the Location header is not needed. Cheers, - jsproat (26 years ago, 10-May-99, to lugnet.faq)
|