Re: Design for (interactively) customizable DSSSL stylesheets
From: Paul Prescod <email@example.com>
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