[I suspect this is old info for those familiar with the history of
DSSSL -- the choice of a language that supports functional (no side
effect) programming language such as Scheme indicates that the spec
developers were quite aware of the potential dangers of more
conventional programming styles.]
Reading external variables can be another problem since you have to
hand-craft some sort of polling or event handling if you expect the
external state might change during a document's use. It's too bad
this is a tough problem with the current XSL (no value dependency
information is maintained, I suspect, in any existing or planned
implementation), since you can provide neat capabilities if you keep
track of the information each layout variable depends upon. This
"constraint-based" approach make it possible to support selective
redisplays (depending on the changes that invalidate previous
calculations) and dynamic displays that depend on information external
to the formatter.
For more on the difference between the usual approach (Random
question: does DSSSL have an event model?) and the more powerful
constraint-based approach, you might want to look at Prof. Ethan
Munson's Proteus papers. (http://www.cs.uwm.edu/faculty/munson/) He
describes an alternative to DSSSL that uses constraints to handle
out-of-order layout, dynamic behavior, etc. The biggest drawback are
the memory requirements for maintaining the dependency information in
large documents.
A less important concern would be the proliferation of scripting
languages, which is a real annoyance from a general service
developer's point of view.