[OpenJade-devel] Re: The Future of DSSSL

[Brandon I. <bi...@in...>]

Quoting Javier Farreres de la Morena <sp...@in...>:
> I am not into the mulberrytech dsssl list, but I wouldn't mind getting into
> it if you tell me how.
> 
   Check out http://www.mulberrytech.com/dsssl/dssslist for info. :)
These posts do not seem to be appearing on the DSSSList.  Hopefully,
that will be fixed soon.

> 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 agree completely.  I was just pointing out that my expertise and
interest lies more in the information handling side.  I certainly
don't mean to neglect the formatting side of things, but I don't feel
I have quite as much to offer, there, so I'm hoping others will fill
in on that side.

> 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.
> 
   Again, I agree.  I just wanted to establish that I was going to
speak only of Jade/OpenJade, as I can not speak for NextSolution, and
also because I think the majority of DSSSL users, by far, are using
Jade, due to it being an open-source solution.
   I certainly mean no offense to NextSolution or its products, mind
you, because, as you pointed out, they fulfill an important role by
providing products that not only offer support for customers who
require it, but also functionality above and beyond what Jade offers,
particularly in the formatting area.
   All that said, I hope that future work on both packages can be
mutually beneficial, especially given the recent comments by Takashige
Noguchi.

> >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.
> 
   All true, in theory.  However, I've examined the Jade (and let me
clarify here that I use the word "Jade" to refer to either Jade or
OpenJade, as the differences between them are minimal, for the
purposes of this discussion) code in order to determine how
alternative grove implementations could be incorporated, and while I
can't enumerate the details right now (it's been a while), I can say
that the way Jade is organized means that (to the best of my abilities
to analyze this) major rework would be needed.
   Matthias Clasen's "Jade Internals" document talks about the layered
architecture of Jade.  I think the problem lies in there not being
clean breaks between the layers.  Further, my experience in object
oriented design tells me that layered designs do not lend themselves
to componentization.

> >   The Scheme implementation at the heart of Jade's DSSSL engine is
> >also custom-made.
> 
> About this, again, I think a good class encapsulation would solve the problem.
> The class would call the Scheme implementation it would need.
> 
   Again, good in theory, but not necessarily in practice.
   I guess the first step, whether in starting a new implementation
with the intent to reuse as much as possible from Jade, or to rework
Jade to introduce new components, would be to create a good map of the
class structure in Jade, both in terms of inheritance and
encapsulation.  Certainly there are automated tools that could help in
this, but I imagine a certain amount of manual work would be required,
as well.  I will try to look into what it would take to do this, but
if anyone else feels like doing a little code analysis, by all means,
let me know. :)

> >   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
> 
   I think you may have misunderstood me.  I'm suggesting that the
Style Language, as it is, could be implemented on top of the
Transformation Language.  No change in syntax or anything.  The only
real difference here is that the Flow Object Tree would be built as a
grove, meaning that a property set would need to be created to
describe the FOT.  This would, potentially, affect the interface
between the DSSSL engine and the formatting backends, but would be
invisible to the user.

> 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.
> 
   Again, I agree.  The lack of a clear, clean interface to groves is
one of the problems I see in Jade right now.

> >   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.
> 
   Absolutely!  This was the main idea behind GroveMinder, and it's
one that I'd like to incorporate into future development.  Properly
designed as independent components with well-defined interfaces, any
of the components (grove, DSSSL engine, backends) could be reused in
other contexts.

> >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?
> 
   Check out section 12.5.1.1 of the DSSSL spec.  General Indirect
Sosofos are sosofos whose value is the result of a DSSSL (Scheme)
procedure applied to one or more "generated objects", the value of
which is generally not known until formatting time.  Thus, for proper
support of this, you'd most likely need a means for the backend to
communicate these values back to the DSSSL engine so the engine can
execute the procedure and return the value to the formatting engine.

> >   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.
> 
   Agreed.  I was just stating that the majority of *current* DSSSL
users have fairly modest formatting needs beyond Jade's current
capabilities, so even a partial implementation of the page-sequence
features could be a huge improvement for many people.  Obviously, for
more demanding applications, such as those in the publishing field, a
more complete implementation would be needed.

> >   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.

   I don't know TeX or the TeX backend well enough to say, but my
hunch is that support for the page-sequence features would require a
major rework of the backend.  Still, this may not be a bad way to go.
The other possibility that I see would be a direct-to-PDF approach, as
used by NextSolution's product, as well as the Java-based backend that
Christof Drescher has been developing.  Perhaps your student could get
some input from these individuals about an overall approach?
   If you student begins by establishing an overall implementation
plan, and publishes this as a framework, then perhaps others could
volunteer to take on certain parts of it, subject to his overall
control.

> 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?
> 
   Jade does have a pretty good interface for backends, so a new
backend, possibly based on the existing TeX backend, should be easy to
integrate.  As I recall, the "Jade Internals" document describes this
fairly well.

> >   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.
> 
   No, I was referring to the "general-indirect" stuff, as I described
above.  For what you describe, I think the best option is to format to
an editable format such as PDF, but that's a whole other discussion. :) 

> 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'm very excited to hear that you have a student who has committed
to working on the page-sequence features.  Please keep us posted on
this.
   When you say you have a student who may want to "develop the grove
model", do you mean extending the SP-based grove implementation to
include more of the SGML property set?  This would be a great
addition, and could easily be done within the framework of Jade, as it
is.

> 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.
> 
   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. :)

-Brandon :)