Re: DSSSL extensions for XSL

[Paul Prescod <papresco@xxxxxxxxxxxxxxxx>]

James Clark wrote:
> > Is an upwards-only call/cc very valuable.
> 
> It's useful for all things you would use return/break/continue for in C,
> Java or JavaScript.
> 
> > I know that it can be used to
> > implement exception handling, but I think it may be more confusing than
> > helpful. A catch/throw special form might be more appropriate. Are there
> > other uses of an upwards-only call/cc?
> 
> Like you, I would find a catch/throw style syntax more natural for this,
> but that has to be balanced against the incompatibility with Scheme.
> There are several Scheme implementations that provide upwards-only
> call/cc (Kawa for example).

Well perhaps we can do what the Schemers should have done years ago (in
my opinion) and create catch/throw special forms which would be
implemented in other implementations as macros on top of call/cc.
 
> > Flow object macros seem like they will be very nice syntactically. Can
> > the flow object macro inspect the inherited characteristics in contexts
> > other than characteristic specifications or do we still have to wait for
> > first class modes for that??
> 
> The inherited characteristics are packaged up into a style object and
> there's no way at the moment to look inside style objects.  First-class
> modes wouldn't help with that.

I realized I hadn't said that clearly when I sent that. I meant that if
you could inspect style objects then you could pass arbitrary
information down the flow object tree in characteristics and retrieve
them in flow object macros by inspecting the style object. But since
this is not possible, we will have to wait for first class modes to pass
information down the flow object tree to be used outside of
characteristic expressions.

Will first class flow objects provide a mechanism for *returning* data
up the execution context tree? In some cases a flow object macro will
want to adjust its properties according to the property of its children.
For instance a box might collapse if it has no content or a section
might create a table of contents only if it has sub-section elements. 

Of course you can figure out the answer to these using SDQL queries and
some smart coding, but that is only the case if you know about the DTD.
But the very concept of flow object macros encourages one to think about
reusing them across DTDs -- about "composite" flow objects that are as
widely useful as the built-in ones. The problem is that these composite
flow objects seem to require more knowledge of their environment than we
want to allow regular DSSSL programmers. But now that Jade has side
effects maybe we can reconsider the idea of allowing the creation of
user-defined composite flow objects in Scheme/DSSSL code. These flow
objects would have access to the sort of information available in the
back-end and could have globally available data structures as the
back-end does.

This will provide a *partial* answer to the question of "flow objects in
Java?" If the flow object can be expressed as the combination of
existing flow objects then it can be done right in Scheme/DSSSL (or
Javascript/DSSSL for XSL). Perhaps with a sufficient "tool-box" of
primitives (like "line", "pixel" etc.) maybe the set could grow to
encompass everything people would want to do.

 Paul Prescod

 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist