Re: SGML/XML syntax for DSSSL

Subject: Re: SGML/XML syntax for DSSSL
From: Derek Denny-Brown <ddb@xxxxxxxxxx>
Date: Tue, 20 May 1997 09:35:17 -0700
At 10:57 AM 5/19/97 +0700, James Clark wrote:
>At 06:49 18/05/97 -0400, Paul Prescod wrote:
>>Let's moot a couple of heretic ideas.
>>
>>Syntax less like Lisp?
>>======================
>>
>>Maybe a CSS-like syntax? I'm strongly supportive of the existing DSSSL
>>syntax for the full DSSSL constituency, but I don't want to turn off
>>Dirty Perl Hackers.
>
>One approach that makes sense to me is:
>
>- Provide an SGML/XML syntax for the non-programmatic parts of DSSSL.  This
>should support calling procedures.  You would also need some very simple
>"expressions" within attribute values (ie +2pt, 10%).
>
>- Use the current syntax for defining procedures.
>
>- Provide a more extensive library of procedures to make it possible to
>handle a wider range of documents without having to do any programming.

This would be a great boon.  I know that, at least within my company, there
are a number of future 'plans' which included DSSSL, including GUI
SGML-editors & style-sheet-editors.  Knowing this company and the resources
it has available to throw at such a problem, DSSSL will be abandoned as too
difficult in it's current form, unless other people provide the tools for
us to use as integration components.  This bothers be since I think DSSSL
is a better long-term solution, and I really fear what might be used
instead.  A simplified, non-Turing-complete model would reaffirm my belief
that DSSSL could be a good choice for such projects, outside of a vendor
with some very significant resources to throw at that specific problem.

>This approach I think also makes sense in the context of GUI tools: they
>would fully support GUI editing of the XML parts, but the Scheme parts would
>be edited as text.

this might be palatable at first, but would be a hard sell agains the
current wave of pseudo-WYSISYG environments.  The document producers are
used to paper and it can be difficult to convince them of the benefits of
moving toward (the relatively infantile) industry of electronic
documentation delivery solutions.  Currently, the short-term business
perspective tends to be that the costs are higher for electronic delivery
and the value-added may not be equivalent.  This is especially true for
large scale document delivery environments with a heavy investment in
legacy systems.

My point is that some good WYSISYG content/style-sheet editors would go a
long way to helping DSSSL get it's foot in the door.  The full
functionality might not be available, but if the system is at least
powerful enough to replace current FOSIs and such solutions then it would
be much easier to make that first, critical step to introduce DSSSL into
their process.  Once DSSSL is in use, and they ask for more features, you
are in a much better position to point them at a good DSSSL seminar.  This
approach would go a long way to helping distribute the cost of moving
toward a DSSSL solution over wider time period.

At 08:25 AM 5/19/97 -0500, Alex Milowski wrote:
>Well, I think "alternative syntaxes" is going to be a whole world of trouble.

I agree for the most part.  What I would like to see is a
cross-over/cross-pollination of some of the DSSSL experts to the CSS
effort.  If CSS and DSSSL could be aimed in such a way that CSS was a
'simplified' subset of DSSSL, using a similar/same model for the document
display representation, then both camps would benefit.  it would mean that
CSS users could migrate to DSSSL (when CSS failed to provide the neccessary
features) with only a marginal learning curve, since they already have the
basic model and are probably just adding a tweak or two to their existing
style-sheets.  Similarly the complexities of DSSSL would not be neccessary
for every style-sheet.

I would hate to see the DSSSL-O effort duplicate the CSS effort too much.
CSS is (very slowly) growing up to become something more powerful.  DSSSL-O
is taking something far more powerful and flexible and scaling it down.
These two paths are bound to cross at some point, at least in terms of
functionality.  If that cross-over was planed for now, I believe everyone
would benefit.

The hard part is coming up with a stipped down model based on DSSSL which
works in the CSS domain.  This is touchy ground, since many of the CSS
advocates are _very_ electronic-delivery oriented and are used to thinking
in terms of HTML.  The trick may be to build an extension to current CSS
which would be simple to impliment (relative to CSS1 which I would
generally rate as trivial already, at least relative to DSSSL) but which
provides some usefull additional functionality (better print/paper support?
I am not the expert here...)

I would hate for there to be YAFSSL (yet another freaking style sheet
language) just when I was beginning to think that DSSSL and CSS would solve
95% of all my style sheet problems....


-derek

--------------------------------------------------------------
ddb@xxxxxxxxxx || software-engineer || www/sgml/java/perl/etc.
  "Just go that way, really fast. When something gets 
      in your way, turn."  --  _Better_Off_Dead_

 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread