(see also: Co Outlining, Transclus Ion, Active Renderer, Wiki And Outlining, OSAF, Structured Writing, Hierarchal Structure, Open Hyperdocument System, DITA)
My focus here is on writing documents (for online consumption, not pretty printing)
note that the entire concept of "document" is pretty messy in Hyper Text)
will think later about handling non-bodytext properties (e.g. PIM fields). (Object Browser)
Imagine doing Structured Writing. Each Information Block is an "item" in the Data Store. It has a label, bodytext (in Smart Ascii), one or more images (blobs) as properties.
Each item has a URL, making text Paragraph Addressable. Any item may have a Name Space/Wiki Name.
Every item can have any number of child items. But Everything Is AGraph, so any item can have any number of parents, not just one.
So a document can be modelled as any node/item, plus all its children.
Which of course could go on forever. And of course stuff changes all the time - items get restructured, rewritten, etc. So there's never really a static "document", and it may be impossible to ever recapture a "version", because changes go All The Way Down.
and of course any reference to a Name Space/Wiki Name with an item's bodytext would link over to that item, so that gets even bushier.
And if there's a whole network of such things, then a child item could reside "on" a different server.
- (It might be a bit tricky to have "your" node A, which include someone else's node B as a child, below which you would like to add node C as a grandchild...)
Do you really want their node D (child of
to be "part" of "your" document? Transclus Ion is nasty stuff. - Actually, this might not be so bad to manage if you think in terms of:
a sea of independent nodes (OK, there can be "side links" among them - esp via Wiki Name use)
- a "document" is basically an arrangement (primarily an outline/hierarchy) of those nodes.
you could probably make the document definition recursive (like a Bill Of Materials), but I'm not sure that would improve things. Or a node's "owner" could define the node's primary/default parent and primary/default localDocument (arrangement of any child nodes). Then a document could explicitly define an arrangement All The Way Down, but at any given node one could jump sideways to its primary/default hierarchy. (OK, that probably doesn't make sense to anyone else, but I think I have it kinda straight in my head...)
Since this is a very dynamic system, everyone needs to be on a Full Peer. (Though I could imagine some way of rendering static items to the File System, so they could be upstreamed...)
or we could use some other transport than HTTP - how about Jab Ber? Or is something more asynch (Message Bus) better for serverless/Off Line-user support?
<hr>
Expanding idea to encompass Messaging
Imagine a messaging system to replace EMail... imagine IBIS-style Group Discussion happening this way. (Note that there's a Threaded Discussion "controversy" to consider.)
Would it still be true that Summarizing Is Necessary? What would you be summarizing?
each node you read could be cached, as your Personal Web Archive (and offline reader) - you'd need to check for updates...
You might replace Instant Messaging the same way. Or, since the more popular use of IM is just chatting, you wouldn't care. But, in another sense, this post-email messaging could be instant...
the Universal Inbox is your reader for all these nodes...
Is there a risk here of encouraging Reduction Ist thinking? Does it become more difficult to keep the big picture in mind?
Would Annotation Systems be created by other people adding children to an item? Would we need a "relationship" property for a link? Would this be the Blog Web?
OK, I've just restated a lot of the OHS work. See esp Eric Armstrong's What's wrong with EMail essay.
Oct'2009 note: see Google Wave. 
<hr>
Con Text: what's the point? (User Scenarios)
Here's one interesting idea: think about Wiki For Collaboration Ware, either where there's a need for offline use, or wherer the team is rather loose (a Federat Ion). Multiple people can work on different parts of a "page" and integrate their changes more easily if you treat it as a collection of nodes.