Subject: Re: (dsssl) Re: The Future of DSSSL From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Wed, 2 Jan 2002 02:19:28 -0600 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: (dsssl) Re: The Future of DSSSL, Trent Shipley | Thread | Re: (dsssl) Re: The Future of DSSSL, Sebastian Rahtz |
Re: (dsssl) Re: The Future of DSSSL, Trent Shipley | Date | Re: (dsssl) Re: The Future of DSSSL, Sebastian Rahtz |
Month |