 | | 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
|
|
(...) 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)
|
