Subject:
|
Re: Working sketch of FAQ item data format
|
Newsgroups:
|
lugnet.faq
|
Date:
|
Fri, 7 May 1999 18:10:04 GMT
|
Reply-To:
|
jsproat@geocities.comAVOIDSPAM
|
Viewed:
|
1894 times
|
| |
|
|
> In lugnet.faq, jsproat@geocities.com (Sproaticus) writes:
> > [...]
> > The Flarn header wasn't pulled in from File B, because it was already
> > defined in File A. Similarly, the Snarf header was pulled from File B, so
> > it was not fetched again from File C. By changing the order of the Include
> > headers, you can set preference for one file's headers over the other's.
Todd Lehman wrote:
> Is the idea behind this so that lower levels can include headers from upper
> levels -- headers such as 'Topic-Level'?
Among other things, yes. Upper levels can benefit too, such as bringing in
'Location' headers (1).
> If so, then do the included headers override what's in the current file
> being processed (by way of having already been included), or do the headers
> in the current file being processed override the included headers (by way of
> having been processed prior to processing of includes)?
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 including file. I
suppose the way to handle this would be to process the lowest-level
includes, then the next up, etc, to the top-level including file.
One thing I'm still unsure about, is how to handle including optionally
repeating headers, such as 'Location' (see footnote 1) and 'Reference'.
Possibly just put them in one big pile.
> What other headers (if any) besides 'Topic-Level' will typically be
> overridden or left blank?
Some others might include: 'Location' (see footnote 1), 'Content-Language',
'Translated-From', 'Translator', 'Include' (2), 'Reference', 'Originator'.
Some we definitely don't want to slurp in: 'Subject', 'Revision'.
> Doesn't this type of include mechanism either (a) require a list of which
> headers get pulled in at include-time and which headers get ignored, or (b)
> accidentally sometimes pull in unwanted headers for other files (such as
> 'Comment' or 'Location' or 'Translated-From')?
True. Arg.
> I guess overall what I'm still wondering about is, what does an explicit
> header-include mechanism give us that the lack of it doesn't? How terrible
> is life without it?
Not too bad at all. :-, Aside from promoting laziness, the only *real* use
for an include directive is for specialized FAQs, but that's really an index
file issue, not a FAQ item issue.
This is becoming pretty messy, and mostly for a dubious benefit. Do you
have any qualms with doing away with 'Include'?
Cheers,
- jsproat
1. Bad plate to put this, in a footnote, but... I think we should split up
separate 'Location's into separate headers instead of commafying them. It
would become more consistent with everything else, and allow for 'Location'
headers to be brought in from somewhere else.
2. Not sure how to avoid infinite loops yet... Maybe if we allow any given
file to be included just once...
--
Jeremy H. Sproat <jsproat@geocities.com>
http://www.geocities.com/SiliconValley/Horizon/5249/
"I prefer the term para-mental. It keeps me out of the loony bin."
|
|
Message has 1 Reply:
 | | 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 (25 years ago, 8-May-99, to lugnet.faq)
|
Message is in Reply To:
| | 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 (...) (25 years ago, 7-May-99, to lugnet.faq)
|
20 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
|
|
|
|
