Subject: RE: (dsssl) Re: The Future of DSSSL From: "David Santamauro" <david.santamauro@xxxxxxxx> Date: Wed, 2 Jan 2002 00:21:19 -0500 |
I would be very interested in contributing as well. I have experience (~2yrs) working with SGML/XML but well over 5yrs programming in C/C++. I think this would be a great opportunity to dissect DSSSL (something I've always wanted to do). Please let me know if I can help. David -----Original Message----- From: owner-dssslist@xxxxxxxxxxxxxxxxxxxxxx [mailto:owner-dssslist@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Trent Shipley Sent: Tuesday, January 01, 2002 21:31 To: dssslist@xxxxxxxxxxxxxxxxxxxxxx Subject: Re: (dsssl) Re: The Future of DSSSL I am very interested in making some contribution to the project since it involves areas I'm very interested in and I desperately need any experience to put on my resume. I regard myself as a very junior programmer however, so someone would need to provide direction, supervision, and mentoring. I would be willing to take on at least part of the task described by B.I. (below) since I don't mind doing documentation as long as the coders are cooperative and actually enjoy the analysis part of programming. I have read the DSSSL spec. once and am printing out HyTime 1997, 2nd ed. as I write this. Presumably there is little point to starting the source code until the underlying problem is understood. > > As I noted, one of the greatest aids to future development > involving Jade would be a good analysis of the current codebase. > Would something like this be appropriate as a project for one of your > students? They could start with the current "Jade Internals" > document, expanding on it through a combination of manual analysis and > automated tools. The results of these efforts could include both > Docbook marked-up material describing the various classes and modules, > as well as some custom markup (largely the result of some automated > tool?) which describes the class relationships. This latter product > could be formatted to produce a hypertext reference in HTML, as well > as, possibly, visual diagrams, say, in SVG? Ah, dreams. :) > There seems to be a consensus between BI and JF de la M on the need improve the modularity and information hiding in the existing SP and OJ codebase. DESIDERATA: At this point it looks like BI and JF de la M will be project organizers. Please consider the following requests. <opinion> A standard network representation of an SGML resource is a Grove. This implies a modular application below the level of OJ that parses and presents the Grovered data. (Is FOT the serial form of this representation?) It is unfortunate that Node Regular Expresions (grove queries), SGML Transforms and Formatting all wound up in the same DSSSL specification. </opinion> <request> Thus far the request is for five separate utilities. 1) An SGML parser 2) An SGML-to-Grove translator with at least two backends 2.1) A C based data-object (structure) 2.2) FOT serialized output 3) Grove queries (node regular expressions. This should be extended to include some sort of PERLescent stream-based regular expressions despite the fact that the leaf nodes of a grove and characters for normal regexes are the same.) 4) Grove Transforms 5) Formatting Furthermore, the new and improved OJ's modular structure implies that it's formatting engine does not in fact provide TeX, PDF, or any other direct output. Instead the client application calls the root formatting object and depending on whether it called the C++ code or the extern C wrapper for the C++ code the client app gets back a Formatted Object Descriptor. The client application then does whatever it does with the Formatted Object Descriptor. (I have a *very* slight preference that the first formatting client be for TeX instead of PS or PDF.) Realistically a formatting client will be needed to even debug the DSSSL formatting module. So: 6) Formatting client(s) 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. </request> <opinion> 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. There is no reason that DSSSL's functionality couldn't have been implemented in ANSI BASIC. For any number of good business reasons why at least one flavor of DSSSL should have been implemented in BASIC. There is no *necessary* relation between the DSSSL idea and Scheme. The relation specified in the ISO spec should be broken. </opinion> <request> Please make available a C++ (and if possible a C wrapper for the C++) API to the DSSSL function. This will allow implementations of DSSSL function in language families that are more popular and accessible than LISP. Please make the first programmer-friendly interface to the C++ DSSSL API an ISO compliant implementation in Scheme. </request> <opinion> I agree with JF de la M that from a market perspective the Formatting parts of the project are more important. However, there is a non commutable property for queries, transforms, and formatting from the perspective of software engineering. It is "easy" to go from queries to transforms to formatting by building each stage on the basis of code from the prior project stage. Though it is possible to use the formatting language to produce general transforms it would be silly to do so. 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. </opinion> DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: (dsssl) Re: The Future of DSSSL, Jean-Marie Kubek | Thread | RE: (dsssl) RE: The Future of DSSSL, DPawson |
Re: (dsssl) Re: The Future of DSSSL, Brandon Ibach | Date | Re: (dsssl) Re: The Future of DSSSL, Trent Shipley |
Month |