Two days later, I wrote to xml-dev:
[Isn't it funny they way you can carry around a crazy idea in your head for ages and then, out of nowhere comes just the discussion to trigger externalisation]
AN INITIAL IDEA FOR AN XML ÜBERDOCUMENT SHELL
What I would like to see initially, is a shell-like application that has an interactive command-line that takes shell-like notions such as a working directory (and the ability to change same), starting of applications, redirecting of input/output to/from files, piping to other application and applies them to an XML überdocument.
So this "shell" would have the notion of a working element (command 'pwe' (=pwd) will tell you what the working element is). You can change working element with the command 'ce' (=cd) followed by an XPointer.
Elements contain XML content or they could reference an unparsed entity (for the issue of whether by ENTITY attribute or XLink see below). Some unparsed entities (perhaps with an appropriate NOTATION) are applications that can be "run". Instead of files, these applications work on nodes in the überdocument element tree.
I imagine that applications would be a lot more modular as most of them would be working on exposed data structures. Rather than a monolithic email/PIM application, you'd have simple applications (applets? no; how about application elements => "applements"). One applement would POP your mail and graft in on to an element in the überdocument. Another (perhaps just XT running an XSL stylesheet) would list the subject headings. Another would enable you to read email. An editor applement would let you compose a reply message and then a final applement would send the mail via SMTP.
A GUI can come later, but for now, I'd love to see an implementation of what I've just described. In something like Python it should take no time at all to do.
<sidebar>
Is the überdocument a single XML document with multiple entities or more than one XML document?
At first I thought that entities would provide the perfect mechanism for an XML überdocument to be spread over multiple files. For at least two reasons, I now suspect XLink might be the way to go:
1) you can give the links semantics which might prove to be very useful 2) you avoid the document entity != legal external parsed entity problem I raised in an early post
That having been said, it is important to note that the whole point of the "überdocument" notion is that it is logically treated (perhaps not at the XML parser level but at a level not too higher up) as a single document. Changing working element involves giving an XPointer not URI+XPointer.
</sidebar>