(dsssl) The Future of DSSSL: Concrete proposals

Subject: (dsssl) The Future of DSSSL: Concrete proposals
From: Javier Farreres <spanish@xxxxxxxxx>
Date: Fri, 04 Jan 2002 12:30:44 +0100
This message was sent yesterday, but due to my inexperience with the list rules
I included the text as an attachment, and the message was sent back.

----Text of the message----

Since I offered some of my students to further develop OpenJade some time has
passed, and several people
have talked. Two weeks ago I told you all I have one studend who has commited
developing the page model as
far as he can in the time he has (more or less one semester). Some other students
are studying if they like
this project as final work for their studies.

I have been very interested reading the many oppinions that have appeared, although
I am don't agree with
all of them.

The main flow of oppinion which I deny is that which opposes XML and SGML. Many say,
go for XML or it will
not be useful. The first thing I say is I want to help the complete support for
DSSSL, and it has nothing
to do with SGML nor XML. But upon reading the XML standard, it is very clearly a
language designed for
internet transmission, and its design aims go for easy of parsing and such. SGML is
designed as a general
markup language. It has many optional features which are seldom used, I agree, but
they are there to be
used. Rather than design something directed to the XML segment, I prefer to go to
the origins, and if some
XML people want to use it, they will be able to. As I see, the main differente
between SGML and XML is
namespaces (which use the notation of concurrent markup, why?). Didn't the web
ammendment of sgml make it
fully compatible with xml?. Anyway I think the real aim is not SGML, but HyTime.
SGML and DSSSL is the
first step towards the complete support of HyTime. I must confess I have read and
completely understood
SGML and DSSSL standards, but I am not yet familiar with HyTime, although I am
trying to, despite its
modular redaction that makes it so complicated to understand, from my point of view.
Many of us are
shouting to the XML people about the dangers of DOM approach. Groves are a data
model, DOM are different
views layered one on top of the other, withount a clear end in the level of this
layering.. I am sure the
W3C people didn't take groves into account because they didn't understand it. There
can be no other reason,
as it is such a complete model, even allowing different views of the data.

Anyway, as I said, it is just a matter of oppinion. And I think this discussion can
be taken to the
infinite, and we wouldn't solve anything. What is not an oppinion is that OpenJade
needs improvements, and
there are parts of DSSSL which remain unimplemented. Many say OpenJade is very good
as it is, and yes, they
say it because they don't know what they are missing. Some individuals have offered
help, and someone
suggested that I take on the organization of the task. I am not in the position of
developing code, and I
would accept the task of coordination. After all, I must do it for the students who
will be doing their
final projects on OpenJade.  But as I see in the sourceforge OpenJade site, there
are already some project
administrators, and I think it is they who sould say something about it. In my
oppinion, better than one
coordinator, due to the kind of work, it is better to have a coordinating commitee.
And anyone who wanted
to help should just show up and say it as the two who offered help did already. I
like, for example, the
way DocBook is organized. It seems it works very well. We could copy its
organization, which I don't know
internally, I only speak by impressions, but they are really doing a great job, and
our work could help
them also developing a better docbook standard.

There is a little document called "Jade Internals" which I discovered lately. It has
some clues as to what
is done in Jade. But it is very limited, at least in the version I have read. I have
tried to read it from
the link in netfolder and some error appears when looking for
http://www.netfolder.com/DSSSL/OpenJade%20Internals/docbook.css, the file is
missing, so I downloaded it
with wget. Brandon Ibach, who seems to know a lot about Jade implementation, has
pointed out the different
modules that exist now in Jade, and has shown possible enhancements and limitations.

In my oppinion there are the next areas of work (I am now trying to remember, I hope
I don't forget
something):
-SGML parser
-Grove Builder
-Grove model
-SGML generator
-Scheme parser
-Expression language
-Transformation language
-Style language
-Query language
-Flow object tree (someone suggested dropping it and incorporating into style??)
-Backends
Anyone who wants to collaborate should say which part he is interested in.
The coordinators will  not be in the position to demand anything from people who
offer their free time. But
I think there must be a commitment on your part if you offer your help.

The steps to be taken should be to offer your help to develop one of the parts. You
could be sometimes
redirected to other areas which are not yet covered by anyone, or, in case you are
very interested, you
would be directed to the one who is already developing it so you can help.
The order of tasks I would suggest are:
        1- study the code of OpenJade for the layer you have selected
        2- draw a UML class diagram showing the actual code
        3- include the diagram in the Jade Internals document
        4- study the text of the standard and try to complete the class diagram to
accomodate all the
classes needed
        5- propose a final class diagram which would support the complete
definitions of the standard to be
studied by other members and accept comments
                note: I think the main objective should be good class design,
encapsulation, independence,
inheritance, polimorphism amd such. And olso to permit the use of parts of OpenJade
in other applications;
for example the grove model is the most reusable part, in my oppinion.
        6- establish a final class diagram for the layer.
                6.1- incorporate class diagram to the complete Jade class diagram
and study interferences.
                6.2- amend the partial class diagram if needed
        7- transform the OpenJade existing code to the new class diagram, with the
changes needed to keep
it funcional.
        8- start to develop the new methods
        9- when needed, raise a Request to modify the class diagram to adapt things
which were not taken
into account at the start
                note: this shold be done with care, as it can affect the code done
by others
The idea would be also to make a full class diagram of Jade, so two people are not
developing the same
class independently, or incoherently.

This document is thought of as an initial document to develop with the help of you
all. I would like you
who know about the internals of Jade to point out the real areas of work. I am not
sure if I correctly
separated the different areas of development or if I forgot some. And we should
think not only about the
existing layers, but also in the future layers that should be needed. Also about the
tasks I have numbered,
is there any other comment, some subdivission of steps? There should be a commitee
of persons, the
sourceforge administrators perhaps, to study the requests and coordinate changes?.

Well, I hope you like my proposals, or you dislike them at all. There is at least
something to discuss
about. I have a cold now and I could not write it in a netter way to be a formal
proposal, but I think it
is too preliminar. I hope it can be done when some of you have offered your comments
on it.


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

Current Thread