(dsssl) RE: The Future of DSSSL

[Javier Farreres de la Morena <spanish@xxxxxxxxx>]

>   So, I'm going to fall back to discussing these topics on the
>DSSSList.  I'm also addressing this message to the OpenJade
>Development list, just in case there are people there, not on the

I am not into the mulberrytech dsssl list, but I wouldn't mind getting into
it if you tell me how.

>   Let me start by stating my bias, which is that I'm an information
>processing geek, so I tend to shy away from the formatting side of
>things.  So, forgive me if I don't put as much attention towards those
>issues, and I hope that those more involved in that side of things
>will prop up that part of the discussion.

In my oppinion, formatting and information are of equal importance. It follows
the eternal discussion that has appeared in art along the history about
form and matter. Matter without form is bad, as is bad form without matter.
Good information badly shown cannot be understood, but a perfect formatting
for void information is not very useful.

>   I'll start with generalities and work towards specifics.  While I
>acknowledge that there are other DSSSL implementations out there, such
>as those offered by NextSolution, by and large these days, DSSSL means
>Jade or OpenJade.  Neither of these packages are being actively
>developed right now, and it is my opinion that this is unlikely to
>change anytime soon.

As I see it, both must exist. OpenJade is the open source solution, the
take it as it is option. The Nextsolution is the comercial one, a tool which
has a company besides, someone you can contact and obtain help. It is the
organizations who must decide what to pick, depending on their objectives.
About nextsolution I am not going to tell them what they must do. But OpenJade,
I think, should seek perfection and maximum standardization. Noone is going
to win money with OpenJade, so it doesn't matter how long it takes, it must
be the best tool and cover the whole DSSSL standard, doesn't matter if some
parts of the standard are not well understood right now, they will be sooner
or later.

>handling.  Jade's DSSSL engine is built on top of SP, and can not
>feasibly be separated from it.  Nor can Jade easily be put atop an
>alternative grove implementation, such as one built with a
>lighter-weight XML-only parser or one built atop a database.

Hmmm, I think I don't follow you here. As far as I know, Jade and OpenJade
are implemented in c++. It means classes and objects, encapsulation and
all of this. If classes are well defined, internal implementation of classes
is not visible from outside. This way, changes in the internals of classes
don't affect the external use of classes. An alternative grove implementation
should be possible. And is the aim is to accept an XML parser, grove plans
should allow to define the group of classes and properties for the XML information,
I think.

>   The Scheme implementation at the heart of Jade's DSSSL engine is
>also custom-made.  While there is no real inherent problem with this,
>it does preclude the ability to take advantage of improvements that
>might become available if Jade were instead built upon an independent
>Scheme implementation, such as optimization improvements,
>pre-compilation and even ports to new platforms.

About this, again, I think a good class encapsulation would solve the problem.
The class would call the Scheme implementation it would need.

>   Lastly, I have long felt that DSSSL's Style Language would be best
>implemented as a layer atop the Transformation Language.  I think many
>would concur that this approach has been validated by a similar design
>in XSL, where the XSLT language serves as a generic transformation
>tool, with the XSLFO grammar being one possible target.  Very few are
>even familiar with the DSSSL TL, largely due to a lack of
>implementation of it.

I am not sure if I agree with you in this part. We all know XSLT lacks an
underlying model. For this reason it doesn't distinguish between elements
and formating objects, and it can only transform elements into elements.
DSSSL's transformation languate is aimed to the transformation of groves
into groves, not elements into elements. Allowing an approach like the one
given by XSLT would mean that flow object trees followed the groves structure,
but this is not what I understand from the standard. I think the DSSSL approach
is much more powerfull, because it provides independence between model and
formatting

>   Now, having royally trashed our favorite DSSSL tool, on to my
>point.  I believe the best way to reinvigorate DSSSL implementation is
>to "start fresh" with a new implementation.  However, I think it would
>be a mistake to throw out everything that's been done, so I want to
>make sure that everything worth keeping from existing implementations
>is reused.  But first, the overall design.

I am not so deeply informed about the implementation of OpenJade.
But if I were to implement, let's say, groves, I would aim to a class definition
completely encapsulated, so that noone would suffer from changes in the
internal representation of groves.

>   For the grove implementation, the logical start would be to use
>Jade's existing SP-based grove, but integrate it through a generic
>interface, such that any number of other implementations could be

Of course I think this is the way, take profit of what is already done,
but try to indepent the different parts of it. I have been thinking about
groves, and I think the implementation should be so that it could be used
outside Jade. Many tools would benefit from a grove model: sgml-oriented
editors, databases. The aim of the grove model implemented for Jade would
be to allow the used from outside the Jade tool.
An option I have spoken with my students is to try to develop a relational
model for the grove data model, and some application to insert a parsed
SGML document into a database, and some translation from SDQL to SQL.

>   The DSSSL Transformation Language is actually fairly simple, so it
>shouldn't take too much to implement.  Henry Thompson's DSC
>implemented it, and could serve as an example of how to approach it.

Yes, transformation language is very reduced and with few constructs.

>for, among other things, two-way communication between the backend and
>the DSSSL engine, which is needed for certain more advanced features
>of the Style Language.

Sorry, what do u mean with two way communication?

>   This is probably the most requested feature for Jade.  While I
>doubt most projects require every feature of the page-sequence and
>related objects, there is certainly a very real need for more complex
>layout than is possible in the current backends.

I can tell you publishing companies need complex page formatting. The multiple
column option of Jade is really limited. Columns are one of the mosts obvious,
but flow object sincronizations are important, flow object referencing and
such, are very important features.

>   Javier, how would you like to see a project to develop a backend
>(or enhance an existing backend) for Jade with at least partial
>page-sequence support?  Would it make sense for your student to "lead"
>the project, perhaps setup via SourceForge, to allow others to
>contribute?  Takashige (pardon me if that's not the appropriate way to
>address you, informally), would you (and possibly others with
>knowledge of high-end layout techniques) be willing to serve as a
>"technical advisor", as well as whatever other efforts you might wish
>to contribute?

I already have a student who has accepted developing page-sequence related
things. In my oppinion, the best option is to extend the tex backend. I
have told him to read the TEI SGML introduction, and to read the ISO DSSSL
introduction to have a wider knowledge. The more help he can have the faster
he will go.
As I see it, he will have to implement a transformation from a grove to
a flow object tree following the style rules. With this flow object tree
he should implement a way to output the tree, and also a way to generate
tex code for the tree. What I don't know is if jadetex should be also touched
or not. All of this would be implemented with c++ classes. Is it correct
everything I have written?

>   Ideally, the needs of this group would help drive the design of the
>new, more powerful interface between the DSSSL engine and the
>formatting backends.  Depending on the timing of various efforts, it
>my be possible to fit this new (or enhanced) backend on to the
>existing Jade implementations, minus some of the features which rely
>upon services not offered by Jade (such as two-way communication
>between the DSSSL engine and the backend).

I don't know what is this two-way, but it can be something I have been thinking
lately. It would be like allowing editing of the formatting, like revising
the format, and moving by hand these things which have not been properly
placed. More or less what Pagemaker or Quark in a not standardized way.

We are finishing the semester here in Spain, and many students are looking
for final projects to develop. In the last week I have offered to five students
the development of parts of jade. Only one of them has committed to take
the complex page development. I will try to convince some other student
to develop the grove model, but noone more has accepted any other part of
jade. I hope one more of them will take it, but it is very hard to know.
Anyway, when the semester begins more students will be looking for projects
to develop, and I will start again the same thing.

I hope some of you can help us (me and the students) to speed up the initial
inevitale work of getting into the things and learning what has been done
and which files to touch, and to solve the problems we find during the task.

Javi




 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist