Re: (dsssl) Re: The Future of DSSSL

[Trent Shipley <tcshipley@xxxxxxxxxxxxx>]

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