Conditional actions in XSL?

[Meltsner, Kenneth J]

     My biggest concern with using *any* language with XSL would be the
     potential for odd things when language functions have side-effects.
     If a function or subroutine sets the state of an external variable,
     then it's possible that external operation might occur *every* time an
     element is redisplayed.  I believe the spec (rightly) states that
     side-effects are not allowed and that XSL's behavior (and the state of
     the variables involved in the side-effecting function) will be
     undefined if they are used.

     [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.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)