A great interaction paradigm, but definitely later than the text-processing
work. I'd say that a explicitly knowing the design principle involved is a
key issue, since lots of people have invented specific content markup
schemes with whatever macro package was available. The oddly hard thing was
noticing that this process can be abstracted in general.
MVC does include this key distinction between model and view abstractions.
In text-processing the notion of controllers has generally not been an
issue until recently, although that is one possible model for properly
specifying user interaction mechanisms for hypertext documents. [Actually
this is a bit of a lie, since I think embedded applications already existed
in NLS, but I don't know enough to be sure. On the other hand, this may be
part of how NLS implemented its shared editing views].
Embedded Javascript certainly _isn't_ the answer to that question.
Some have advocated simplifying MVC to Model/Controlled because the view
and controller are so tightly linked that they're hard to reuse
independently. For documents, there are similar issues, plus the fact that
it's much more convenient for users and authors to have a single resource
to specify _all_ formatting and interaction parameters. In addition, two
stylesheets translates to two extra HTTP requests, an additional cost that
could be a problem.
Architecturally I'm curious as to what people on this list think. If we
ignore network efficiency issues, would XML format specification be cleaner
if documents had separate style and interaction sheets, or a single
property sheet that specified all such parameters?
-- David
_________________________________________
David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com
http://www.cs.bu.edu/students/grads/dgd/ \ Director of Development
Graduate Student no more! \ Dynamic Diagrams
--------------------------------------------\ http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW \__________________________