David Crossley wrote: > > 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/
No, I indend that will never be more than two incompatible versions supported, the current and the 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. Ok, will do it. > > 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. Oh, I'd love to have Cocoon serve its own pages, believe me, but apache machines are simply too loaded for that (and I don't personally have the access level to be able to run this, nor I want that responsability on such an important servers since I'm no system adminitrator of any sort!) Maybe we could use Nagoya (Sun E4500, *big* beast!) for that and redirect: Sam, you have access to that machine, right? > > 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. What about moving over to nagoya? it's solaris machine so java support rocks, plus it has more RAM than we need :) It could also be a wonderful load test. > > 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. My personal design pattern is: if it's only one and doesn't require nesting, should be an attribute. This results, IMO, in increased readability and reduced verbosity without any degradation in expressivity. But that's my personal opinion only. > > 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. Shouldn't take long to write. You guys come up with the CSV files and I write the generator, ok? :) -- 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]
