I've read the 'xml-deviant' column on xml.com and found it extremely interesting for a couple of reasons: 1) it's an xml-centric and non-apache-centric view of this project 2) it's a user-centric, show-me-the-stuff-that-I-need perspective Now, from that perspective, our site sucks. Big time. 1) it's slow and heavy, for no reason [this is fixed with the new layout] 2) it's sub-project oriented: gives no overview of the Apache XML Project Overall impression: it's a rusty container. Why should I (user) trust the technologies it contains? - o - I personally volunteer to change this and improve it because I don't want people coming to xml.apache.org to stop there, I want them to keep on getting back and visit our site. Here is the plan: 1) change the layout in order to speed up the browsing experience [this is done with the new layout] 2) revamp and rewrite the common sections 3) place a newscolumn and a project status column on the homepage (just like I did several years ago for java.apache.org, go there and take a look) 4) write the "evolutionary software map" along with explainations on where to find stuff, overlap between them, reasons for this overlap, community directions and all this. Cocoon will generate the site. I will write a script (probably an Ant build file) that will gather the XML documents from the various CVS modules and then run Cocoon on top of those to generate the site and place it live. Then I'll write a section of the site that explains how this works and where to modify stuff for making it appear there. The goals are: 1) users must have the impression that the site is 'live' and well maintained 2) users must have the feeling of the quality of our software from the site 3) users must find it useful to get back frequently to the site 4) users must find it interesting to explore the site and discover our technologies but without requiring deep interaction with the code in order to get a feeling of it. I also have a personal itch to scratch: I would like to have a simple way to know the following information from all the different projects: downloads: - downloads per version per week - total downloads per version mail messages: - mail messages per mail list per week - total mail messages per mail list mail list subscribers: - subscribers per mail list per week - total subscribers per mail list CVS commits: - CVS commits per module per week - total CVS commits per module The idea is to have a cron-ed script (Perl?) running weekly (on sunday) on the apache servers that append this data in comma-separated files, for example (numbers are invented): cocoon.downloads: year,week,downloads 2001,43,3898 2001,44,3849 ... cocoon.downloads.totals: year,week,download-totals 2001,43,348498 2001,44,352849 ... and so on for every subproject. Brian, do you see any problem for this? Don't worry, I'm not asking you to do it, we'll provide the scripts, but we need root access to run them and add to the cron list. Cocoon is then able to transform the above into XML files, process them with XSLT stylesheets that generate SVG graphs and then rasterize them into graphical images embedded into the site pages. Results are: 1) the site remains static, no additional load on apache.org machines 2) everybody can have a simple window on the status of the subproject (not only users, but developers from the other projects and apache people outside of xml.apache.org) 3) we show off the power of XML technologies for publishing. I volunteer to do all the above (but I'll need some help on the above scripts since I'm no Perl guru of sort). As for DTDs, I'll try to stick with the DTDs we have and adapt the stylesheets to the different DTDS (or write adapting stylesheets between the various DTDs) In case this is not possible, I'll present here alternative plans. But keep in mind that the idea is to simplify your life: if this is not the case, I have failed and I need to fix that. Comments? -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- In case of troubles, e-mail: webmaster@xml.apache.org To unsubscribe, e-mail: general-unsubscribe@xml.apache.org For additional commands, e-mail: general-help@xml.apache.org