Re: Design for (interactively) customizable DSSSL stylesheets

Subject: Re: Design for (interactively) customizable DSSSL stylesheets
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri Mar 28 11:00:13 1997 EST
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
prepended? 
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
defined?

 Paul Prescod

Current Thread