(Someone will shortly begin firing 22 caliber rounds into my office[1],
so I will leave this verbose.)
Claim:
Textual inclusion is a fundamental indirection/abstraction mechanism,
required if www is to scale in volume and duration.
Argument:
1 Inlining of dynamic/living documents is needed.
2 This can be done at server or at client.
3 You sometimes(often?) dont want to do it at server.
Elaboration:
1. What happens if you cant inline dynamic information?
Options:
- Copying, and then either maintaining consistency or
accepting obsolence.
- Hyperlinking to it, even when you need it in flow of the doc.
- Doing both, and push the burden onto the human.
- Giving up.
2. ...
3. ...
Mumbles:
I have fuzzy recollection of a cern doc which mentions brewster at
TMC in cambridge. He switches jobs. Does tim 1- leave it outdated
(print model), 2- hand edit it every time brewster moves (toy system
model), or what?
What if I wish to inline think.com's phone number or mailing address?
Suppose I write a living document criticizing unix. To illustrate
my point, I wish to quote some single FAQ entry. Do I 1- copy it, thus
losing the benefit of improvements to the FAQ, 2- point to it, forcing
me to use a document structuring I didnt want, 3- periodically hand
edit it (not), 4- have an agent edit it, n- or what?
Can I create a composite document with out either losing consistency
or looking like a gopher menu?
Inlining, by virtue of making the web representation more powerful,
might be used to address other problems.
Caching might be addressed by something (remotely) like
<A HREF=<INLINE HREF="http://wwwnamed-host/cern-cache">/pub/mumble>cern</A>.
WWW cache inheretence then follows the DNS hierarchy.
Must go.
Clarification:
[1] Ceiling lights being rehung from concrete.