Subject: Re: (dsssl) Re: The Future of DSSSL From: Trent Shipley <tcshipley@xxxxxxxxxxxxx> Date: Tue, 1 Jan 2002 23:05:26 -0700 |
> > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: (dsssl) Re: The Future of DSSSL, Brandon Ibach | Thread | Re: (dsssl) Re: The Future of DSSSL, Brandon Ibach |
RE: (dsssl) Re: The Future of DSSSL, David Santamauro | Date | Re: (dsssl) Re: The Future of DSSSL, Brandon Ibach |
Month |