Stefano Mazzocchi wrote: > We have released Cocoon and this is a great thing. > > Now we have to improve the web site a little bit. > > 1) location of Cocoon 1.x documentation: > > I propose to move > > http://xml.apache.org/cocoon1 > > into > > http://xml.apache.org/cocoon/old/ > > which I believe it's better because the URI is version-free and > future-compatible: this means this location identified "the previous > generation of Cocoon, now considered obsolete, but still used by many".
+0 ... I abstain because i do not yet understand the issues. I gather that you intend that there will never be another major version of Cocoon. Otherwise, we will need cocoon/very-old/ as well as cocoon/old/ > 2) graphic look: > > I propose to update the site skin using the new xml.apache.org look > proposed over at [EMAIL PROTECTED] Ted, what's the status > of this? > where can we find the stylesheets you came up with? > > This mainly because the site is simply too heavy: it's ok to show off > the power of generating raster images out of SVG files, but this is > clearly too much. +1 ... the current website is a huge turn-off. Even local build docs is very frustrating. I wish for a nice clean look-and-feel like the Avalon website. > 3) Clean up documentation: there is a lot to do, but here are things > that bug me: > > a) there is no visual difference between sections (i.e. User) and pages > (Who We Are). > > b) there is very little meaning associated with the sections (how in > hell are readers supposed to know what CTWIG is?) > > c) we should have a "community" section. > > 4) enhance site functionality: > > a) searching: we must come up with a way to search content, even > forwarding to Google is better than nothing. +1 ... However, it is hard to have interactive search on a static website. Again, if only Cocoon was running on the server, we could use the new Cocoon-Lucene functionality. Sure, links to Google might help. However, Google's content is at least one month out-of-date ... a bit useful, nevertheless. > b) community information: > > - graphs of people subscribed on the mail lists > - graphs of messages on the mail lists > - graphs of downloads > > I see much more valuable to use the SVG rasterizer for such graphs > rather than "waste" it to generate the sitebar text. In order to do > this, though, we need to gather this information. +1 ... this would be great for us all to see. Yes a far better way to show off SVG. > My idea is to have a perl script (or equivalent) run every week that > comes up with this information and places it on a specific location > (this should be done for every xml.apache project). I do not understand how the graphs would get regularly updated on the website for everyone see. At the moment the site documentation is only updated on an occasional basis. Oh, how we wish for a site that was actually running Cocoon rather than a static web site. > Unfortunately, the mail list subscription information is reserved by > root, so we need a high level of access in order to do this (Sam, do you > have that kind of access level?). The compressed MBOX files can be found > over at: > > /www/xml.apache.org/mail/cocoon-(users|dev) > > while the web site logs are in > > /x2/logarchive/www/2001 > > The ideal solution would be to have this processed information already > XML-ized, but it's probably easier to "append" a line than to add an > element to an XML file. We could use CSV and do the XML-ization at > Generation level. > > Something like this would be great: > > cocoon.list.cocoon-dev: > cocoon.list.cocoon-users: > > year,week,subscribers,messages > 2001,01,348,983 > 2001,02,358,839 > 2001,03,334,1093 > 2001,03,343,1293 > ... > > which could XML-ized as > > <list> > <item year="2001" week="01" subscribers="348" messages="983"/> > <item year="2001" week="02" subscribers="358" messages="839"/> > ... > </list> > > or > > <list> > <item> > <year>2001</year> > <week>01</week> > <subscribers>348</subscribers> > <messages>983</messages> > </item> > ... > </list> > > which is more verbose, but could be easier to create using SAX events > and easier to process with XSLT stylesheets (why attributes are so > neglected in the XML world? bah, I love them so much) http://xml.coverpages.org/topics.html#elementsAndAttrs has arguments for and against each. I am still unclear, but think that i lean towards structured data as elements rather than attributes. > Then we could easily transform this into SVG with an XSLT stylesheet and > have the raster graph generated automatically without human > intervention. Again, note that XML-ization of the CSV file can be done > by a CSVGenerator which is piece of cake to write (I volunteer to do it > if this is accepted) Excellent, Cocoon needs a default CSVGenerator anyway. --David Crossley > Also, > > cocoon.downloads > > year,week,downloads > 2001,01,294 > 2001,02,384 > > I'm not very good at UNIX administration, so I'd be more than happy if > somebody else provides the scripts and installs them on apache.org :) > > Ok, enough for now. > > Please, place your votes or indicate your > comments/suggestions/criticism. > > Thanks. > > -- > Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
