> Why do you want *documents* that do this? It sounds a lot like what you
> want is *programs*. Now, we may entertain the argument that says there is
> (or should be) no difference but that seems to me to be a fundamental
> confusion of process and product.
Well, you could play with words and say that what I want is documents
that have programs attached. That's fine. I tend to think it
translates into more or less the same thing. I definitely want to be
able to add arbitrary user interaction to the semantics involved in
viewing a file.
To try and illustrate the interconnectedness of documents and programs,
let me go off on a bit of a tangent. Imagine a standardized universal
generic document architecture -- we'll call it HTML++^^* -- that makes
this clean separation, so that it has a markup language with program
"attachments". Now, you can imagine translating HTML++^^* into ODA, or
Troff, or whatever you want, assuming that they also have appropriate
"attachment" capability, and that translation might well be (with a few
strange exceptions that don't really matter very much) computationally
tractable. Document translation is really hard, and fraught with peril,
but at least theoretically possible. But what computational theory
tells us is that the attached programs are themselves NOT translatable
to other languages in the general case. To my mind, this says that we
really HAVE to have a standardized programming language.
Now, I think we all agree that a standardized document architecture,
even though it might be theoretically a bit less necessary, would be a
Very Good Thing. If you were to turn everything on its head and embed
your document architecture *inside* your programming language, you'd get
the document format standardization as a *consequence* of the
programming language standardization, as an "added bonus". Note that
I'm not actually advocating this approach -- I think Postscript is a
very good example of the limitations of this approach, in fact, and of
the way that solving one problem can create twenty more -- but merely
trying to point out that the two areas are more interconnected than is
apparent at first glance.
Do I know what the ideal solution is? Absolutely not. But I do feel
confident that the best way to move forward is evolutionary development
based on proven models and technologies. I think embedding a
Safe-Tcl-like programming language inside an HTML-like simple markup
format is the obvious next step in this direction. There will be
problems with it, and inadequacies, of course. That's how evolution
works.
Does it have to be Safe-Tcl? No. Does it have to be HTML? No. But
using things that already exist and work reasonably well will allow us
to focus on fixing the inadequacies in those systems, rather than on
inventing new systems that will have their own unanticipated
inadequacies. It will get us there faster, that's all. -- Nathaniel