Re: From CSS to DSSSL

[Paul Prescod:]

| > | DSSSL has been deployed to generate HTML (in Jade -- I have built a
| > | whole website this way), and Jade will generate HTML+CSS as soon as CSS
| > | is supported in a standard way by major browsers. It is important to
| > | remember though, that shipping dumbed-down documents over the web is
| > | second best.
| > 
| > True, but I predict that you will see a lot of XML+CSS (as per-element
| > embedded style attributes) being generated from databases.  That's
| > what I want to see coming out of docs.sun.com as soon as I can get our
| > people to work on the experimental XML output some more.
| 
| Why not use a fixed CSS or DSSSL stylesheet rather than embedding that
| information into each element?

Because (a) if I really want a separate stylesheet I'll use DSSSL
rather than CSS, (b) it's really easy to generate style attributes on
a per-element basis using an SGML server like our AnswerBook Online
server at docs.sun.com, and (c) you then enable style handling by
browsers that don't have to be nearly as smart as the ones that
interpret stylesheets and you also simplify the download and
autochunking aspects.

However...

I've just had a discussion with the guys on our AnswerBook Online
team, and they think I'm wrong about this.  In fact, *I'm* beginning
to suspect that I'm wrong about this.  Our plan is to subject the
question to experimental verification by providing two basic flavors
of XML output from docs.sun.com: XML with embedded CSS styles, and XML
with class attributes and references to both a CSS stylesheet and a
DSSSL stylesheet.  This will give experimenters three different
possibilities to play with, and we'll see what shakes out.  (I will
try to remember to post something here when this is all ready, but
anyone interested in actively following this experiment should
subscribe to the xml-dev list.  To do that, send mail to
majordomo@ic.ac.uk and put the line

subscribe xml-dev

in the body of the message.)  We're also leaning toward providing CSS
stylesheets for the regular HTML output from docs.sun.com as well,
which would make for a nice assortment of different approaches to
compare.

| I think that your experience learning DSSSL is very different from
| everyone else's. You were the first, with basically no examples or
| tutorials. I learned from your examples and found it very easy going.

(Anyone who wants to see the examples that Paul is referring to should
look at

   http://sunsite.unc.edu/pub/sun-info/standards/dsssl/egs/10_mail.zip
   http://sunsite.unc.edu/pub/sun-info/standards/dsssl/egs/10_mail.tar.gz

   http://sunsite.unc.edu/pub/sun-info/standards/dsssl/egs/20_tstmt.zip
   http://sunsite.unc.edu/pub/sun-info/standards/dsssl/egs/20_tstmt.tar.gz

   http://sunsite.unc.edu/pub/sun-info/standards/dsssl/egs/21_shaks.zip
   http://sunsite.unc.edu/pub/sun-info/standards/dsssl/egs/21_shaks.tar.gz

These are good introductions to XML, too.  Note that I did the XML
design but did not write the stylesheets used in 20_tstmt and
21_shaks.)

| Imagine learning SGML from the ISO Spec -- you'd be convinced that it
| was a bitch to learn too. But people learn it every day.

I don't find this quite as attractive a comparison as you may have
been hoping.  :-)

| Presumably you were also working with quarter-implemented tools, which
| means that instead of using some simple DSSSL feature (like ipreced)
| you must have uses dozens of lines of code that emulate it.

That's true, but the fact remains that many of us find functional
languages fairly difficult to deal with.  I don't think that better
examples would have helped that part.  I also don't think that it
would have helped to use a procedural language, and I am *quite* sure
that it wouldn't have helped to use a monstrous set of declarative
kludges of the kind that some people seem to be trying to make out of
CSS.  DSSSL is solving some very hard problems rather elegantly, but
the nature of those problems requires it to be a tool that a lot of us
who didn't major in computer science find nonintuitive.  That's just
the reality of the situation, and I don't see any way around it.

Which is not to say that there aren't a fair number of people who find
functional languages natural and easy.  Here's a report just posted by
Henry Thompson to prove it:

| From: ht@cogsci.ed.ac.uk (Henry S. Thompson)
| Date: 17 Apr 1997 09:48:16 +0100
| Newsgroups: comp.text.sgml
| Subject: Re: Is DSSSL hard?
| 
| Yesterday I taught a one-day intensive DSSSL introduction to 10 people
| with a range of backgrounds.  None of them knew Scheme or LISP before
| they started.  As far as I could tell, by the end of the day most if
| not all of them believed they could proceed to write simple DSSSL style
| sheets themselves.  The expression language itself did not seem to be
| a particularly significant factor.
| 
| One line I have found successful in the past is to point out that
| imperative languages such as C, Pascal, Fortran (and Java and C++ and
| Smalltalk) usually start out by explaining the difference between
| statements and expressions, and saying "Basic rules for statements are
| ...; basic rules for expressions are ...".  The thing about pure
| functional languages such as ML or DSSSL is, in these terms, that they
| have ONLY expressions.  That seems to help some people.
| 
| ht

Other people break out in hives when they see something as simple as

   (define (expt b n)
     (if (= n 0)
	 1
	 (* b (expt b (- n 1)))))

YMMV.

| I have not yet seen anything that is easy to do in CSS that is hard to
| do in DSSSL except things that depend on the implied "built-in" HTML
| stylesheet.

Well, that's a lot of things.  Have you seen the code that Anders
Berglund wrote to handle CALS tables in the DocBook DSSSL stylesheet?
And the stuff it took for me to implement lists wasn't much fun
either.  Of course, the up side is that Anders and I can now make
tables and lists behave any way we please, but that flexibility comes
at a price.

Please understand that everything I'm saying is in the context of
DSSSL as something you create by hand in a text editor.  PostScript
wouldn't have become a widely accepted programming language if that
were the only way you could create a PostScript file, either.  What
I'm saying is that as things stand right now, in the absence of DSSSL
stylesheet editors, DSSSL is a language primarily aimed at experts who
need to solve hard problems.  Since the kind of problems that interest
me are along the lines of how you automatically format 20,000 pages of
Solaris documentation at a whack (both in print and online), this
current reality doesn't bother me at all, and I sure that it won't
bother the folks who face tasks like autoformatting 200+ editions of
TV Guide every week or autoformatting all the Yellow Page directories
put out by a telco every year.  To us, DSSSL is a godsend, and it's
just one of the rather hairy tools that we use to do our jobs.

It will be very interesting to see the side-by-side comparison that's
been promised; I agree that most people don't understand yet that the
simple stuff really is just about as simple in DSSSL as it is in CSS.
But an even more interesting comparison will be when there are equally
capable stylesheet editors for both languages.  That's something for
which we'll probably have to wait a while.

Jon

Received on Thursday, 17 April 1997 19:37:46 UTC