Mulberry home page

DSSSList Archive

Mulberry Home Page
Previous by Date
Next by Date
Previous by Thread
Next by Thread
Index by Thread
Index by Date
Index by Subject
Index by Author

Re: Design for (interactively) customizable DSSSL stylesheets

From: Paul Prescod <>
Date: Fri, 28 Mar 1997 11:05:10 -0500
David Megginson wrote:
> Norbert H. Mikula writes:
>  > How can I tell the user agent what things are customizable.  I can
>  > take the whole stylesheet and make it editable for the user, but
>  > that would scare off most of them.
> Instead of extending DSSSL (or trying to enforce coding conventions),
> I think that the best approach would be to maintain your stylesheet
> info in a more constrained, proprietary format and export it to
> DSSSL.  As far as I know, this is the approach that most RAD systems
> take -- they cannot import arbitrary C++ or Java code.

The situations are subtly different we are talking about parameterizing
the "runtime environment" of a DSSSL specification. This is like making
Java or C++ applications that can "report" what parameters they accept
on the command line or through method calls so that you can "drive" them
from a centralized interface. Actually, there are rudimentary ways that
Java and C++ programs can report those sort of things (OLE and Active-X
for C++, getParameter() and Java Beans for Java).

I think that James' idea would work fine as the DSSSL equivalent. It
isn't clear to me where he is proposing the *parameter values* of those
parameters should go: on a command line, in a %usermods;, in a file
pre-pended to the DSSSL script? It matters, because it would change how
the script itself is written: 

Does it need to import %usermods;? 
Does it need to be missing a DOCTYPE so that the relevant values can be
Is it rather a fully valid DSSSL spec. with "default values" in a
special section that is erased and changed? 
Is it a fully valid DSSSL spec *except* that certain things are not

 Paul Prescod