Lists Home |
Date Index |
- From: "James Tauber" <email@example.com>
- To: "XML-Dev Mailing list" <firstname.lastname@example.org>
- Date: Tue, 9 Feb 1999 01:46:50 +0800
[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
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
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
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.
James Tauber / email@example.com / www.jtauber.com
Associate Researcher, Electronic Commerce Network
Curtin University of Technology, Perth, Western Australia
Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)