RE: (dsssl) Re: The Future of DSSSL

["David Santamauro" <david.santamauro@xxxxxxxx>]

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