DSSSL style editing (was: RE: Positioning...)

(I've broken this out as a separate thread in case anyone wants to
continue the discussion.)

[Mike Wexler:]

| Even this could theoretically be handled in a declaritive style sheet.

Yes, of course.  Any behavior you can think of could be handled in a
declarative style sheet.  That's not my point.  My point is that for a
behavior to be supported in a declarative style sheet language,
someone must have already programmed that behavior, and that someone
isn't me; I don't get to specify new behaviors.  I have to go to a
standards committee if I want new behaviors.

| I think your last case highlights the strength of style sheet
| languages like DSSSL. They allow you to express things that aren't
| likely to be anticipated by the designer of the style sheet
| language. All the other ones [the examples other than the last one]
| are things that are likely to be anticipated by a well-informed
| style-sheet language designer.

I don't want to depend on the ability of a well-informed style-sheet
language designer to anticipate a functionality that I don't know I
need until tomorrow.

| Note, there is a major downside to procedural style sheet
| languages. The style sheets can be very hard for non-programmers to
| edit. Creating a GUI-based word-processor or web page creation tool
| that can read an arbitrary XML document and its DSSSL style sheet and
| allow the non-programmer user to edit the look of the document is a
| very difficult problem.

Yes.  But it's not an insuperable problem if the requirements are
clearly understood; see below.

[Chris Lilley, quoted out of order:]

| > * Make every other paragraph in this sequence of paragraphs bold.  If
| > I add a paragraph in the middle, automatically change all the bold
| > paragraphs that follow it to medium and all the medium paragraphs that
| > follow it to bold.
| 
| OK, that one is a style change. The others are structure or semantics
| changes. Which doesn't mean they aren't desirable things to do, just
| that they aren't the job of a style sheet.

My idea of a style sheet is much broader than yours.  Maybe we should
call these things "output specifications".  I want to control the way
the document looks.  Deciding whether or not a TOC is going to be
generated in a particular place or whether the names in a telephone
book are going to appear ordered by last name or first name is to me a
decision about how the document looks, just like decisions about type
faces and relative positioning.  The distinction that I make is
between content (the names and numbers in the phone book) and the way
the content appears under a particular set of circumstances.

| > Not necessarily.  PostScript is a programming language, and lots of
| > robust WYSIWYG authoring tools generate it.
| 
| True. But I have only ever met one program that would read in arbitrary
| PostScript (as opposed to special, essentially declarative subsets such
| as Adobe Illustrator eps), let me graphically select and edit things,
| and then save it back out again.

This is the key to understanding how DSSSL style editors will get
implemented.  In PostScript, all halfway decent tools create files
that any PostScript output device will render correctly.  Similarly,
any conformant DSSSL application will be able to handle a DSSSL
stylesheet correctly, regardless of the tool used to create the
stylesheet.  In both cases, the thing that is produced is a program
(one procedural, the other functional), and in both cases, it is
unreasonable to expect that documents or stylesheets will be freely
interchangeable among editing tools; the guaranteed interchangeability
is among different output processes.

But here's where the two cases fundamentally differ.  I have to
interchange documents between editors; I don't have to interchange
stylesheets between editors.  Stylesheet design is much more private.
If companies A, B, and C are all making DSSSL engines and all making
DSSSL style editors, I can just pick the style editor that suits me
and use it with any of the DSSSL engines.  That's enough
interchangeablity to make the process work.  If I need to collaborate
with someone on the creation of a stylesheet, we can agree to use the
same editor.

If we relax the (effectively impossible) requirement that all
stylesheets be interchangeable between all style editors, then a lot
can be done to help authors create stylesheets.  In a format like XML
that supports deep, labeled structures, a smart editor should be able
to create a workable starting stylesheet simply by looking at the
document structure.  (ArborText makes a FOSI editor that does this.)
If the author knows enough to identify which elements are
title-bearers, a smart application could create a very respectable
stylesheet; it could even allow the user to select between a
repertoire of canned treatments the way that many word processors do.
In fact, given real structure to work with, a DSSSL editor should in
theory be able to do an even better job of heuristic stylesheet
construction than current word processors.

Jon

----------------------------------------------------------------------
 Jon Bosak, Online Information Technology Architect, Sun Microsystems
----------------------------------------------------------------------
 2550 Garcia Ave., MPK17-101,           |  Best is he that inuents,
 Mountain View, California 94043        |  the next he that followes
 Davenport Group::SGML Open::ANSI X3V1  |  forth and eekes out a good
 ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB  |  inuention.
----------------------------------------------------------------------

Received on Tuesday, 4 February 1997 20:07:55 UTC