(see also: Co Outlining, Transclus Ion, Active Renderer, Wiki And Outlining, OSAF, Structured Writing, Hierarchal Structure, Open Hyperdocument System)

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

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 A Graph, 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 B) 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 JabBer? Or is something more asynch (Message Bus) better for serverless/OffLine-user support?

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 BlogWeb?

[OK], I've just restated a lot of the OHS work. See esp Eric Armstrong's What's wrong with EMail essay.

ConText: 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.

User Options Recent Changes Help Page