Conditional actions in XSL?

[W. Eliot Kimber]

At 11:24 PM 1/28/98 -0000, Tony Stewart wrote:
>         ... require pretty serious use of scripts to fire external
>queries and set/get memory variables.* To the extent that XSL contains
>non-critical restrictions on when we can make those calls and what we
>can do with them, I'd like to see those restrictions removed.
>
>*(Though an alternative to maintaining traditional memory variables
>could be to manipulate attributes of the parsed tree, provided that the
>scripts were allowed to get at it... style rules manipulating the DOM...
>there's food for thought.)

In the grove-based world of HyTime and DSSSL, the outside is represented by
constructing a grove from it and then interrogating that grove.  For
example, I could define a property set that describes the objects I care
about in my system, including the states of various dynamic properties
(hmmm, sounds like an Express data model....) and then write software that
constructs a grove from those objects.  Given a grove, I can then use
normal grove processing to act on it (e.g., a DSSSL or XSL spec).  Queries
are represented in the same way: the result of a query is always nodes in a
grove--any grove, it doesn't matter, as long as its a grove.  For example,
if I want to be able to query the mouse pointer, I might define a property
set like:

<propset>
 <classdef rcsnm="mouse">
  <propdef rcsnm="xcoord" datatype="integer">
   <desc>X coordinate of mouse pointer</desc>
  </propdef>
  <propdef rcsnm="ycoord" datatype="integer">
   <desc>Y coordinate of mouse pointer</desc>
  </propdef>
  <propdef rcsnm="button1" datatype="Boolean">
   <desc>Up or down state of button 1. True=down, False=up</desc>
  </propdef>
  <propdef rcsnm="button2" datatype="Boolean">
   <desc>Up or down state of button 2. True=down, False=up</desc>
  </propdef>
 </classdef>
</propset>

Now when I query the mouse, I construct a grove of one node with the four
properties shown.  I can then iterrogate those properties using my DSSSL spec:

(define query-mouse
  (external-procedure "UNREGISTERED::DRMACRO//Procedure::query-mouse"))

(define (mouse-b1-down?)
  (if (node-property 'button1 (query-mouse))
     (make paragraph
        (literal "Mouse button 1 is down"))
     (make paragraph
        (literal "Mouse button 1 us up"))))

Where "query-mouse" is my mouse state grove constructor. Now, every time my
master processor applies this style spec, the result will reflect the state
of the mouse.  If the style is re-applied as quickly as possible, then I
have what appears to be an "interactive" document (when what I really have
is a very responsive presentation system).

Clearly you could model everything that user interface systems like VB and
PowerBuilder do using this approach, although I don't know if it would
provide any benefits (it might, who knows?).  Of course, how much
difference is there between interpreting VB code and applying style sheets
like the above in a tight processing loop? None, I would think, except that
the grove-based approach may have an additional layer of abstraction that
either makes new things possible or slows the system down to unacceptable
levels (or both).

Note that in the grove formalism, there is no notion of "manipulating" a
grove in the abstract processing model. Rather, if something changes, you
construct a new grove.  Of course, under the covers you probably aren't
really completely reconstructing the grove, but to outside observers (that
is, the programs operating on the groves), the grove just is.  Thus, if
your grove reflects the state of the system, if the system state changes,
you construct a new grove to reflect the new system and reapply your
processing. Obviously, if a system anticipates reacting to change, there
has to be some sort of event loop that causes what was done before to be
redone.

Note that there's nothing that prevents some part of a style sheet from
constructing a new grove.  This is what happens when you use the sgml-parse
function in DSSSSL--you construct a new document grove and the function
returns its root. This is the functional equivalent of manipulating the
grove you've got.

That's why "dynamic HTML" is silly a-priori: you're not manipulating the
document, you're creating a new abstract object from it.  Or else you've
got a script-driven editor.  In either case, the dynamism isn't in the
HTML, it's in the presentation processor, which is the way the world has
always been.

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>

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)