Re: (dsssl) Re: The Future of DSSSL

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

Quoting Trent Shipley <tcshipley@xxxxxxxxxxxxx>:
> 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.
> 
   Uh, why?  What's wrong with XSLT?  Admitting that I was not real
fond of it at first, I have since found it to be a very useful and
user-friendly tool for simple to moderate transformations.
   Beyond a certain level of complexity, of course, it becomes a real
drag, as you have to jump through many hoops to work around its
limitations.  That's when I wish I had the power of a proper
programming language like DSSSL.
   I have no desire to compete with XSLT.  See below...

> 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).
> 
   Let me be *very* clear.  I don't care about market share.  I just
want to make better tools available for a technology that I think is
underutilized.  If we can make the technology easier to use in the
process, great, but I'm not about to hack the DSSSL standard to pieces
to accommodate everybody's idea of what the best or easiest programming
language is.
   Yes, I know LISP/Scheme is not popular.  But I will violently deny
that it is any harder to learn than slop like BASIC.  And if it does
take a little longer to learn, so much the better that the user gets a
clue about solid programming practice along the way.
   That said...

> 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.
> 
   I don't want to rewrite OpenJade.  In fact, I'm not even all that
big of a fan of C++, anyway.  (Don't get me wrong, I love C and I love
OOP, but I don't consider C++ to be a particularly wonderful marriage
of the two.)  I'd rather use what can be used from OJ to build a new
system on top of an existing Scheme engine.
   You want a different face on DSSSL?  How about XSLT?  I see no
reason (yet, anyway) why XSLT couldn't be implemented on top of the
DSSSL TL.  If you really want to let people write Java or BASIC code
for document processing, let's figure out a way to interface code
written in these languages as extension functions.  With a
well-defined interface, the user could provide functionality in the
language of their choice within the framework of DSSSL, and without
violating the side-effect free rule, or any other DSSSL tenets.

> Please explain (and probably not for the last time) the importance of a 
> side-effect free Expression Language.
> 
   Honestly, I don't know all of reasons behind it, but I know it's
important enough to have been included in the design of both DSSSL and
XSLT.  I think it's a good match for the processing models of both,
and in a very practical vein, it allows the processor considerable
flexibility to optimize processing if it can count on side-effect free
transformations.
   If you're familiar with PostScript, you may have encountered the
problem of reordering the pages of a PS document.  You could just
break the code up at page boundaries and shuffle them into whatever
order you want, but if any of the code in a page does things that
affect the global environment, you could be in big trouble.  If you
know for a fact, however, that none of the code does this sort of
thing, then you can rest assured that reordering the pages will have
no unwanted effects, because the code for each page simply lays out
that page, with no side effects.  The idea is similar.

> > > 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".
> 
   Okay... so what were you suggesting?  The backends in Jade already
use an API to access the FOT that they must render.  What API are you
suggesting they should be using, and for what?

-Brandon :)

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