[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

an initial idea for an XML überdocument shell (was Re: CORBA's not bori

• From: "James Tauber" <jtauber@j...>
• To: "XML-Dev Mailing list" <xml-dev@i...>
• 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
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>

James
--
James Tauber / jtauber@j... / 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:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: an initial idea for an XML überdocument shell (was Re: CORBA's not boring yet. / XML in an OS?)
    • From: David Mohring <heretic@i...>

• Prev by Date: Clear specs: Audience
• Next by Date: Re: document vs non-document entity (was Re: CORBA's not boring yet. / XML in an OS?)
• Previous by thread: Clear specs: suggestions
• Next by thread: Re: an initial idea for an XML überdocument shell (was Re: CORBA's not boring yet. / XML in an OS?)
• Index(es):
  • Date
  • Thread