Re: (dsssl) Re: The Future of DSSSL

[Trent Shipley <tcshipley@xxxxxxxxxxxxx>]

> > 4) Grove Transforms
>
>    That'd be the DSSSL Transformation Language, of course.  Again,
> this hasn't really seen the light of day in implementation.  It's been
> done, but not much used, so far as I'm aware.  The TL is not easy to
> get started with, mainly due, I believe, to lack of educational
> materials.  But it is very powerful.  I hope we can change this with a
> mainstream implementation and some practical examples of why people
> would want to use it.

We'll have to do better than that.  It will now be necessary to find a niche 
in competition with XSLT.  If not, the whole exercise will be academic.


>
> > I would like to see Grove queries, Grove transforms, and Grove based
> > formatting provided as separate C++ coded utilitities.  Ideally there
> > will also be an interface for plain C through C++'s 'extern' keyword.
>
>    If you mean that the various components of DSSSL should be
> available to be embedded into other applications such that they could
> be used (relatively) independently of each other, I agree. :)

Check.


> > It is unfortunate that DSSSL is an implementation instead of just a
> > functional specification.  In particular, the requirement to use the
> > unpopular LISP.Scheme language family was a marketing disaster.
>
>    Speak for yourself! :P  I think Scheme is an elegant, efficient
> language.  It was chosen very specifically because it is a functional,
> side-effect free language, suited for the task.
>    However, I can acknowledge that Scheme can take a little getting
> used to if you've never seen it before.  But, then, what programming
> language doesn't take some work to get fluent in?  

Yes. Scheme IS more elegant, consistent, ... and so on ... , and more FUN 
than BASIC.

But that is irrelevant.  

At least it's irrelevant in terms of capturing market share.  Note that 
industry has a penchant for EZ-2-Learn programming languages (COBOL, BASIC) 
and efficient to run languages (C, C++) with not too much in the middle (Ada).

BASIC is a @#$% language from the standpoint of CS or product engineering. 
But it is quick, dirty, has a relatively low learning curve, and (perhaps 
most important) has a huge installed base of trained human capital ready for 
hire and partially interchangeable.

If we re-write OJ in modular C++ with an accessible API then it is 
immediately accessible in C++ and can be wrapped for Java and BASIC in a 
native idiom (that is the user will not need to know squat about Scheme or 
about the DSSSL spec.).   The result has an excellent chance of becomming a 
popular product.

>
>    Can't say I'm a big BASIC fan, but when push comes to shove, if
> it's important enough, I see no reason why DSSSL couldn't be fitted
> into any functional language that can guarantee side-effect free
> behavior.  (Yes... the side-effect free thing *is* important.)
>

Please explain (and probably not for the last time) the importance of a 
side-effect free Expression Language.

(Will a side-effect free C++ API necesicarilly provide a sufficient 
no-side-effect scope?  Does the side-effect free scope have to encompass an 
entire stand-alone style-sheet|transform-set|query-set ?)

> > It is not silly to use transforms to produce Formatted Objects (though it
> > might be too costly to do so in terms of performance).  It will probably
> > be almost convenient to write formatting clients using the Transform C++
> > API.
>
>    I'm not sure exactly what you're suggesting here.  What do you mean
> by "Formatted Objects"?  FOTs?  TeX?  PDF?

The "Formatted Objects" corresponds to FOT.  "Formatting client" is a synonym 
for "backend".


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