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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: (dsssl) Table Cell Line Wrappin, Sebastian Rahtz | Thread | RE: (dsssl) The Future of DSSSL: Co, Didier PH Martin |
Re: (dsssl) Table Cell Line Wrappin, Ian Castle | Date | RE: (dsssl) The Future of DSSSL: Co, Didier PH Martin |
Month |