Heresy? Re: DSSSL WWW Enhancements

[Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Let's moot a couple of heretic ideas.

Syntax less like Lisp?
======================

Maybe a CSS-like syntax? I'm strongly supportive of the existing DSSSL
syntax for the full DSSSL constituency, but I don't want to turn off
Dirty Perl Hackers.

Non-Programmatic DSSSL Profile?
================================

What about a non-programmatic profile? There are many things to
reccommend DSSSL to Web users *other* then the fact that it has a full
programming language built in. These includes modes, definitions,
reusable styles, the ability to generate content, query capabilities,
... I believe that it is possible to keep the ability to call functions
without having a full Turing complete programming language if we remove
higher order functions, recursive calls and restrict or remove
(process-node-list ...). I don't claim to have completely thought this
out so I am interested in feedback.

I suggest we consider a non-programmatic version for several reasons,
some vague/philosophic and some easy to understand.


#1. Denial of Service Attacks: DSSSL scripts can go into infinite loops.
That could hang your computer in a bad implementation or slow it down in
a good one. This is one more hassle for browser vendors to worry about.
They've already got security problems up the wazoo. (so maybe they don't
mind another one? :) )

#2. Perception of Ease of Use. If the DSSSL book is 600 pages with half
of the book dedicated to higher order functions and abstraction, and the
CSS book is 300 pages with half the book as filler, people think that
the former is substantially harder than the latter.

#3. Actual Ease of Use. The mental exercise of forcing something into a
restrained Turing-incomplete model can be powerful for determining what
was too difficult in the previous model. The result is usually something
that has 95% of the original language's power but is easier to learn,
use, teach and manipulate programmatically. 

For example the SGML DTD formalism could be replaced with full
Turing-complete DSSSL-based structure-checkers, and it would even be
easier to write validating parsers, but it would be substantially harder
to write SGML editors. The SGML "instance" format could be augmented
with some kind of programmatic macro language such as is found in TeX,
Netscape-HTML or PostScript. But that would be a powerful inducement for
DTD creators to make DTDs that are less accurate reflections of the
data's actual structure. Document structure would be embedded in the
macro facility rather than the DTD. Once again this makes programmatic
handling of these documents a PITA. 

Programmatic transformations of arbitrary DSSSL code *is* a PITA. That's
why we had the big discussion about WYSIWYG DSSSL editors a few months
ago. I would like to think that a subset that did 95% of what most DSSSL
stylesheets do could be controlled through a fully GUI representation
without too much mind-bending. The power and complexity of the
stylesheet builder would probably be on par with a full application, but
not with a programming language.

#4. Doing Things in the "Right" Place. Most of the things that I do in
the 5% of the code in my DSSSL stylesheets that are actually
programmatic are fairly complicated transformations, links and "tricks"
like making exponentially larger headings. But why should these same
calculations be done millions of times on millions of machines reading
my pages rather than once on my server? I suppose there could be a small
class of complicated procedures that depend on the browser window (or
page's) width, but I have not run into a need for these procedures yet. 

Another good reason for doing transformations on the server is that the
server has the whole document, all of the time, whereas the client only
has a portion it has already downloaded. That means that, for instance,
a server can generate a table of contents immediately, but a client can
only do so after it has downloaded the whole document.

I am not sure how my two ideas interact yet. I am also not yet sure that
all or most stylesheets will divide nicely into a
programmatic/transformation part (done on the serve) and a
non-programmatic/display part (done on the client). I have heard rumours
that DSSSL was originally designed in this way. You were expected to use
the transformation language for any difficult stylesheet. I think that
we should reconsider that model for the Web environment.

 Paul Prescod

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