Re: [vote] Reinhard Potz as a Cocoon committer
On Saturday, June 21, 2003, at 10:39 PM, David Crossley wrote: I propose Reinhard Pötz to be a Cocoon committer. +1 Welcome! Diana
Re: [RT] the quest for the perfect template language
On Friday, April 4, 2003, at 09:56 AM, Stefano Mazzocchi wrote: I really don't understand why some of you are so emotionally attached to something like xsl:if test=count(blah) gt; 3 but even more I'm surprised to see 'conservationism' on this list. Are you guys getting old or shy or what? ;-) I'd guess that they are all still too young, in that their eyes aren't hopelessly damaged already from decades in front of a computer screen. Thus, they don't mind -- yet -- straining to catch the meaning through all those pointy tags... ;-) Diana
Re: Is build jetty-standlone needed?
On Wednesday, April 2, 2003, at 08:32 AM, Bertrand Delacretaz wrote: ...I guess Bertrand's purpose is not to use it on production servers, but to have a small standalone server that can be used for e.g. demonstrations. Exactly, demos and teaching. What if the build target were called teaching/demo-target instead of jetty-standalone, with a disclaimer including some of Pier's concerns, so that it wouldn't appear that we were promoting jetty, rather, just helping out our users. Diana
Re: [OT] Porting Cocoon to the Whitespace language?
On Tuesday, April 1, 2003, at 03:53 AM, Bertrand Delacretaz wrote: I'm starting to think that porting Cocoon to the Whitespace language (http://compsoc.dur.ac.uk/whitespace/) could bring a lot of benefits. Apparently this language allows one to get rid of all encoding problems by using a strictly restricted character set. Do other countries besides the US celebrate a pranks/joke day like today, April 1? Or are we the only fools? ;-) Diana
Re: [BUG] cocoon doesn't reload
On Sunday, March 30, 2003, at 05:13 PM, Stefano Mazzocchi wrote: With latest HEAD, if you do http://localhost:/?cocoon-reload=true you get an internal server error that says that you cannot lookup components on a disposed ComponentLocator See also: http://marc.theaimsgroup.com/?l=forrest-devm=104885662503763w=2 Diana
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
On Wednesday, March 26, 2003, at 10:52 PM, David Crossley wrote: Hm. Could be, although this particular subject has been discussed, semi-proposed and whatnot already at some serious length in the past, the usual circular discussion following suit hereafter. I only ever saw haphazard discussion, never a clear proposal, and then suddenly a vote. The discussion then had to happen mixed up with the vote. This approach does not seem to work. I think a discussion intermixed with a vote changes the vote so that people end up voting on different issues -- with no clear cut result. Diana
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
On Thursday, March 27, 2003, at 08:16 AM, Bertrand Delacretaz wrote: Agreed - in this particular case, the best thing might be to cancel the current vote and make a new proposal (taking into account the cocoon-docs alias stuff)? Wasn't Pier going to experiment with this approach and report back? If so, shouldn't we wait[1] for his feedback? Pier? Diana [1] There she goes again, using the #!? word wait ;-)
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
[ +1 ] creation of cocoon-docs module [ ] docs should stay in src/documentation of the code tree module(s) I feel strongly about this, give the past year of my watching cvs commits. The fact remains that many committers don't update both doc branches when committing docs. If someone needs **facts** check out the cvs thread when we were all updating the cvs committer list as active/inactive/emeritus/etc. It's quite revealing to see who updated release branch and who did not. It's also a fact that a vast majority of our docs are identical in cocoon 2.0 and 2.1 branches. The idea of a single docs module is supposed to make it easier and more obvious for committers when committing doc patches. So, if this fails, we need some kind of discussion how to encourage people to be more thoughtful when committing. I'm not going to spend the next year of my commiter life syncing docs in code repos. I also want to respond to some of Jeff's concerns below. On Monday, March 24, 2003, at 04:13 AM, Jeff Turner wrote: Please cast your vote: [ ] creation of cocoon-docs module [+1] docs should stay in src/documentation of the code tree module(s) Because: - With a separate cocoon-docs module, I don't see how the various code-related files (status.xml, jars.xml) are obtained. Locally, referenced via a path set in a configuration file. If code repos aren't available/downloaded, info can also be looked up online via a parsed view-cvs data. Still, I don't think it's too much to expect from committers, to have all three repos. - Making a separate doc module kills outright any future efforts to generate docs directly from code (e.g. a component manual). Not at all. There's no reason a doc-generating mechanism can't look up or gather info/files from other cvs code repos during a docs build. - I think that by default, doc changes should only apply to one codebase (2.0 or 2.1). There are many differences that are *meant* to be there, that could get lost if 2.0 and 2.1 docs are generated from a common source. Not true in our current case. Of course, this may evolve to be the case down the road, but as I said above, most docs at the present time are identical (exceptions: install, catalog, some how-tos, some webapp pages). Diana
Re: [proposal] a new kind of 'dist'
On Monday, March 24, 2003, at 07:50 AM, Bertrand Delacretaz wrote: A source-only distribution is not necessarily harder to use, it all depends how it is packaged and used. ... and documented. Most of the problems I've had with oss make-install-before-try software were related to some glitch, encountered during the make-install, that wasn't answered in the install or readme files. IIRC a full JDK (as opposed to runtime-only) is needed to run Cocoon anyway, so compiling or not compiling does not make much difference. A possible scenario would be: -user installs Java Web Start -user goes to the Cocoon download page, clicks on a JNLP link which starts a small install GUI -install GUI helps user download the Cocoon source (maybe even specific CVS tags), asks for an installation directory, asks for the port on which to run Cocoon, starts the build and then jetty. This is not so hard to implement and would be even easier to use than what we have now. Seems to me the above clearly complements the source-only distribution strategy that Stefano is proposing. Diana
Re: [rant] Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
On Monday, March 24, 2003, at 09:15 AM, Steven Noels wrote: On 24/03/2003 14:23 Stefano Mazzocchi wrote: I don't expect 2.0 to live long after 2.1 is out. There is no reason to. To be really honest, I'd like to see some facts backing this statement. Not technical facts, but truly compelling reasons to make the switch. If people don't go with the flow, or with xmlform, why should there be a reason to switch? Furthermore, there will be differences between 2.1 and 2.2 that inevitably emerge ... I personally think transition periods between software versions are the rule, not the exception. Docs which can point out the differences are helpful, especially to new users. It would be so easy with a single set of docs. I've worked with Cocoon since 1.7. In my experience, we've always been transitioning. I think it's particularly hard it is for users to get up to speed with such differences. Our changes doc is overly terse for new users. If there is something back-incompatible, it's a bug and it will be fixed. Nobody should have problems in switching to 2.1 and if they did, we fix their problems because we (and them) *expect* an easy migration. At that point, there will be only *one* repository for docs and it will live close to the code it belongs to. Sigh. I don't understand, and perhaps will never understand, what this obsession is with keeping docs close to code. In some ways, you could argue the genie is already out of the bottle. Look at CocoonWiki (where docs are far away from code). Does anyone realize there are 44 How-Tos there? Now compare that to our cvs count: 12 (with only half being technical, e.g. not administrative/editorial-oriented). Interesting. snip what=doc types why=agree with Steven / In the future, i would like block-specific documentation to remain inside the blocks. Everything should remain as close as possible to the code: javadocs, tests, metadata in general even documentation, configurations, avalon roles, block metainfo and what not. creating a single docu repository is, IMO, a very dangerous road because: 1) it gives a perception that documents are maintained by somebody else. This perception is already here and it's probably my fault and this is causing pain and trouble to many people. I want this to be fixed in order for the process to be more scalable. But in some ways **many** docs are already being maintained by somebody else -- our users on wiki. Where documents live in some ways should be secondary to how to provide the best access to those who want to improve them. However, I still can't see a future CMS which reads/writes a majority of its doc content from a code repository. It simply makes no sense to me, from a SoC point of view. Some may argue, well we don't have a CMS yet, but a poor man's CMS seems very doable now, given the excellent work already available from many on this very list. 2) it has a short-term impact on a short-term problem that is an evidence of a much bigger problem: our inability to do faster releases. we should design the entire system to allow us to make faster releases and this should be our goal, even if potentially disruptive for the short term. I don't see the point in addressing a perception which surely isn't generalized. Some people like to work on docs, and they will, and the entrance barrier should be 'low enough' for them. Some people believe plenty of Javadoc will do the job, alas to be read only by co-developers IMHO. But we can't force anyone of them to become the other - we should support both styles. Making Cocoon user documentation independent of Cocoon itself might be a good first step, that's why the Forrest transitioning is really, really good. I agree I said something like 'we the doco people'. What I meant was the 'people usually contributing to documentation'. Some of them are developers, some of them not. My own belly tells me that people will write more and better user documentation if they get some proper playground. Having to worry about code sitting right beside their documents will not bring peace in their minds. +1 Well stated. Diana
Re: [rant] Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
On Monday, March 24, 2003, at 10:34 AM, Steven Noels wrote: My own belly tells me that people will write more and better user documentation if they get some proper playground. Having to worry about code sitting right beside their documents will not bring peace in their minds. Ok, please, explain to me why the cocoon CVS module is not a proper playground for people writing docs because I don't understand. A few Belly Thoughts: + Consider what we are about to implement in 2.1. Forrest generates our web site and docs, based on the contents of xdocs. What if docs people want to experiment? How can we do that if the place where docs live, next to code, it automatically considered final by our publishing mechanism. Therefore, all experiments either break the automatic publishing or get published to the web (which we may not want). + What about prototyping new doc approaches, like reference pages for logicsheets, as Andrew recently proposed. What if we need some special jar for that, something totally related to docs, not the cvs. Where shall we put it? Bloat the code repo for docs-only needs? Put it in Forrest? Well, what if it's outside the concern of Forrest or we don't want to wait for Forrest -- e.g. experiment a little internally? + CMS issues, already raised in previous posts. + What if we start some global docs transition, say based on adding Dublin Core data, etc. What if we have only a partial set of docs changed over. Wouldn't a docs module, with an experimental/head branch, be a great place for this collaboration? Diana
Re: cvs disruption
On Sunday, March 23, 2003, at 02:59 AM, David Crossley wrote: snip / Stefano Mazzocchi wrote: Diana Shannon wrote: For example, current forrest build capability with cocoon's cvs is only possible with Forrest CVS, not the last Forrest release. This violates your building on sand philosophy. I am not sure what you mean here Diana, it is working now. I'm not saying it isn't working. I'm saying the **only** reason it works now is because we are using a cvs-based version of an outside project, not a released version. Stefano recently stated in: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104619931816392w=2 never commit code that depends on non-released stuff and I'm just pointing out that we are doing that here. snip / Stephan and others have done one excellent step: getting Forrest to process the Cocoon docs as they are now (DTD v1.0). Going to the next stage is what Diana is rightly concerned about. All right. Since there is circular dependency between cocoon and forrest, I would suggest we release cocoon 2.1 first, allow forrest to release a new version based on 2.1 and at that point forrestize our docs. how does that sound? But this circular dependency will always be there, so why not just get on with it. Anyway, Forrest uses a recent stable version of cocoon-2.1-dev, i.e. just off the bleeding-edge. I agree we should get on with it too, as long as we don't break existing doc build capability. I think we should rely on the cvs version only for this transition stage. In the future, I don't want the docs build dependent on a cvs which from time to time will break. While the responsiveness of Forrest committers is incredible, I think Stefano's principle stated above is a best practice we should follow, especially for something like doc building (given the fact users just want docs, not necessarily the latest-greatest code which produces such docs). Diana
Re: [vote] Geoff Howard as Cocoon committer
On Sunday, March 23, 2003, at 08:55 AM, David Crossley wrote: I propose Geoff Howard as Cocoon committer. He also contributed an excellent tutorial on custom generators. +1 Diana
Re: [vote] Forrestizing Cocoon and more
On Sunday, March 23, 2003, at 08:38 AM, Stefano Mazzocchi wrote: 1) cocoon moves to forrest for its documentation production +1 2) if so, cocoon does it before releasing 2.1 +1 3) if so, I'd like a 'fast-yet-potentially-disruptive' move rather than a 'slow-yet-carefully-planned-not-to-disrupt-anything' one. +1. However, we've already figured out we can transition while maintaining existing doc builds (via different sitemap files), as long as we can rely (temporarily) on the cvs version of Forrest. A separate docs cvs will also ease the disruption to existing code repos. Interested persons should follow up on these and other threads on cocoon-docs: proposal to use forrestbot for docs http://marc.theaimsgroup.com/?t=10484113781r=1w=2 stages of transition http://marc.theaimsgroup.com/?t=10484312892r=1w=2 Diana
Re: [vote] Andrew Savory as Cocoon committer
On Sunday, March 23, 2003, at 08:22 AM, David Crossley wrote: I propose Andrew Savory as Cocoon committer. He has been involved with Cocoon since mid-2000 and more intensely during the past year. +1. I was lucky to meet him in person and can confirm his first-rate ideas and experience. He's offered some really welcome strategies for docs! Diana
Re: cvs disruption
Responding to Steven and Stefano here: On Friday, March 21, 2003, at 05:23 PM, Steven Noels wrote: there's a lot of stuff out there and we should be able to work on this as a team. Even if the transition is carefully documented (as you already did at great length), I assume there might be issues, and then it would be good to have a common set of working files, in CVS, when issues arise. See below. It's not only about carefully documenting a transition but also about completing the transition outside of the cvs. Whether the working files (build files and a few configuration files) lived in Forrest or Cocoon cvs, didn't matter to me. It was the idea of using ant to set up a virtual cvs environment until changes were complete and then checking them into cvs. The idea was not to break existing builds until transition was complete. Nothing more. AND On Saturday, March 22, 2003, at 04:53 AM, Stefano Mazzocchi wrote: Inside, we are all equal so once you get it can either be a democracy (ask first, wait for momentum to build, potentially forever) or a do-ocracy (do first, rollback if they jump on you or keep going if you feel you're right). Diana or anybody else: there is something that bugs you and nobody is stepping up to the plate to do it and no momentum is building and nobody seems to care? just do it! Ah, but I did do something. The in-process content and configuration files simply didn't live in the cvs because doing so would have broken the existing and future docs build indefinitely. Granted, most of that was due to the fact Forrest, at that time, didn't yet convert doc-v10 docs on the fly which is no longer the case (i.e. I would have had to check in doc-v11 versions of all docs). Please understand, I'm **not** trying to judge how you refactored the build. Perhaps in your case, there was no other way to implement the changes. I guess I was hoping to suggest -- given the power of ant -- that we can set up prototype cvs environments where we can learn about the implications of our changes over time, even if the cvs changes under our feet, without disrupting the work of others. While our cvs was officially alpha (even though not all committers knew that) it is clear from the past few weeks of feedback that a number of people **perceived** our cvs as almost beta (thanks to all the great bug-fixing we have here) and were using it as beta -- right or wrong. I guess I'm questioning the timing of disruptive cvs changes, so close to a beta release date. Perhaps it's just the nature of open source software, that a tremendous amount of energy is unleashed right before a release date. Perhaps there's no other way. Still, it feels, to be honest, like poor planning. If we follow the maxim of release early, release often I fail to see why there needs to be this kind of disruption before releases. If the releases weren't spaced so far apart, what difference would it make if we need to wait a little longer for some new capability? Again, I'm just trying to learn here. Not trying to pass judgment. Diana
Re: cvs commit: cocoon-2.1/src/documentation/xdocs/ctwig/sample/transformations/basic03 basic03-01.xml basic03-01.xml.ignore
On Saturday, March 22, 2003, at 09:14 AM, Stephan Michels wrote: No, I mean not ignoring for the validation, I mean ignoring for the documentation generation process. At the moment you couldn't generate the docs by Cocoon. I want to make the step invasive as less as possible. Stephan, many thanks for your work on this. I had this same problem the last time I did this. It appears that no more than one sitemap.xmap can exist in the same project.content-dir, even if it has a different name. Thus, to have Forrest ignore Cocoon's existing sitemap, we have to rename it. But this breaks the existing Cocoon docs build because it can't find the (renamed) sitemap. Diana
Re: cvs disruption
On Saturday, March 22, 2003, at 11:13 AM, Stefano Mazzocchi wrote: Perhaps it's just the nature of open source software, that a tremendous amount of energy is unleashed right before a release date. Perhaps there's no other way. Still, it feels, to be honest, like poor planning. If we follow the maxim of release early, release often I fail to see why there needs to be this kind of disruption before releases. If the releases weren't spaced so far apart, what difference would it make if we need to wait a little longer for some new capability? This is a very good point. So, do you suggest to postpone forrestization for post-2.1? say for 2.1.1? Not necessarily. It depends on how much time we still have. And forrestization can occur in stages. For example, current forrest build capability with cocoon's cvs is ony possible with Forrest CVS, not the last Forrest release. This violates your building on sand philosophy. We can change our cvs to work with 0.4 Forrest, but it involves committing doc-v11 versions of many files and deciding what to do with doc-v10-related files. If we simply eliminate the doc-v10 files, we will break the separate doc-building capabilities of our webapp documentation set. If we keep both versions, we have a maintenance nightmare. This is being discussed on cocoon-docs, with debate on how/if to include Forrest itself in our cvs, but there's no consensus yet, IMHO. Whatever solution is decided may take some time and tweaking to implement, that's all. And I would hate for it to hold up a release. We have a list of outstanding issues, some already outdated by recent activity, posted at http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal Ongoing thanks to Jeff and Stephan for their work to date on this. Diana
Re: Setting up a PMC mailinglist
On Friday, March 21, 2003, at 08:15 AM, Steven Noels wrote: So, if we have a volunteer to update the site, and we all agree, we can start straight away. There's movement on the -docs list and perhaps also a Forrest quantum leap blossoming, so we'd better do this before or after this assumably disruptive step. Web site is currently generated from cocoon-2.0 repo. Forrest effort is impacting only 2.1 at this time. I volunteer to update the site. As long as javadocs aren't involved, it's not a big time issue for me. Diana
Re: xml.apache.org cvs details wrong
On Friday, March 14, 2003, at 08:16 PM, David Crossley wrote: However, this raises an issue. I presume that considering Cocoon is now a top-level project, that all reference to the Cocoon project should be removed from xml.apache.org That will be tricky because the xml-site CVS module contains all of the documentation for the Cocoon website. Sorry, I'm not sure what you mean by the last sentence. I realize you were away on holiday and probably missed this, but FYI Stefano proposed that we use redirects to handle the transition to any revised web site URI space for Cocoon. This should help the above issue as well, at least somewhat. By the way, I also got swamped this week and have not yet updated the cocoon site, based on proper mirror URIs. I'll finish that this weekend. Diana
Re: [RT] Cocoon's own publishing system
On Tuesday, March 11, 2003, at 03:22 PM, Andrew Savory wrote: On Tue, 11 Mar 2003, Diana Shannon wrote: I agree 100% with Andrew that two clearly separated repositories won't really improve on what we had. But it's all we have at the moment. Sure. I'm happy to help try and refactor it down to one archive. Or perhaps we could set up cocoon-docs with the content from 2.1 and then go through and import any 2.0 content that is missing? I'm assuming 2.1 is a superset of 2.0 content. You could say that. A majority of the core docs are the same. Only a handful of docs are different at the present time. Clearly this will start to change is we get more docs for various blocks/samples and if we start importing wiki content. Do you have a particular approach in mind? If so, then this discussion should probably continue on cocoon-docs. Really glad to know you are interested in helping. Diana
Re: [RT] Cocoon's own publishing system
On Wednesday, March 12, 2003, at 12:22 PM, Steven Noels wrote: Stefano Mazzocchi wrote: So, should we perform 'forrestization' of our documents to go ahead with the plan? That's not a strict requirement, just cronifying 'cvs update', 'build docs' and some 'cp' to a live website will do ATM IIUC. Don't forget that the web site has a number of redirects. We need to copy-over/transform any .htaccess file(s) as necessary for a revised web site build, not the standard docs build. Diana
Re: Snapshot links at Cocoon website
On Tuesday, March 11, 2003, at 05:32 AM, Pier Fumagalli wrote: I suggest linking to http://xml.apache.org/cocoon/mirror.cgi#nightly but I guess that's your intention ;-) Yes, but at that point we'll have to re-build the site once again... Ok, we shouldn't be so limited in rebuilding the site as often as necessary. Here's why it has been tedious and time consuming in the past, at least for me. 1. Many, many committers weren't updating release and head branches with their doc updates. It took time to scrutinize differences in the branches, to make sure all relevant docs were in the release branch, which is what is used to generate the web site. 2. Updating the live site repository is time consuming, at least for me, on a slow dial-up connection (I live in a rural area of the US with no broadband option). The api docs directory is the time killer here. I spent eight hours, one night, simply performing a cvs update followed by a cvs commit. The most recent update wasn't so bad. The commit/update took only 2.5 hours. 3. I was really excited about Forrest transition, thinking the automation would save me all of the above time which I could devote to docs content. Unfortunately: - only a few committers participated in the trial run, so it seemed to me, interest/support is not that great. - Forresters seemed to suggest, and I could be wrong, that the live site cvs update would **still** be required even with Forrest. Thus, I failed to see how the transition would make my volunteer committer life any more liberated, since this time killing step was still necessary. I'm happy to help with updating the site based on the revised cvs mirror links discussed in this thread. However, I can't do it until later this week. In the future, I think it's better if more committers would share the burden of updating the live site cvs every now and then, particularly those with greater bandwidth connections. In the hopes that this will happen, I'll post detailed instructions on how this can be done on wiki. (I've posted email instructions on two separate occasions in the past which I will now fine tune.) Diana
Re: are we ready to move to cocoon.apache.org?
On Tuesday, March 11, 2003, at 07:30 AM, Pier Fumagalli wrote: I would move it in a slightly different way, that will help us to be more flexible wih the new/updated documentation for v2.1 comes out: Why not have this now for alpha/beta docs? It would save some tedious manual synching. There's probably ways to speed up cvs live site update/commits with some directory reorganization. For example, for the latest update, I didn't even touch the api docs. But their top-level position, intermingled with all other docs, made updates and commits have to inspect the hundreds of files therein. Diana
Re: [RT] Cocoon's own publishing system
On Tuesday, March 11, 2003, at 10:49 AM, Stefano Mazzocchi wrote: 1. Many, many committers weren't updating release and head branches with their doc updates. It took time to scrutinize differences in the branches, to make sure all relevant docs were in the release branch, which is what is used to generate the web site. Agreed this is a problem. Hopefully, now that we have two clearly separated repositories, people will document only in the appropriate one. I agree 100% with Andrew that two clearly separated repositories won't really improve on what we had. But it's all we have at the moment. 2. Updating the live site repository is time consuming, at least for me, on a slow dial-up connection (I live in a rural area of the US with no broadband option). The api docs directory is the time killer here. I spent eight hours, one night, simply performing a cvs update followed by a cvs commit. The most recent update wasn't so bad. The commit/update took only 2.5 hours. Oh, god. I didn't know that. This is a shame. I'm sorry Diana. I know you don't pay dial-up per-minute fees as we normally do here in europe, but still. No, I don't pay per-minute fees. And what I describe was a worst-case scenario. Some days are slower than others. It blows my mind, observing the speed difference, when I perform a cvs update on the xml.apache.org server. we must make a better system. 3. I was really excited about Forrest transition, thinking the automation would save me all of the above time which I could devote to docs content. Unfortunately: - only a few committers participated in the trial run, so it seemed to me, interest/support is not that great. I would like to know the issues that are still left on the table to solve and work on them. Forrest is clearly the way to go and the site transition give us the opportunity to think about it. You can read the joint proposal at: http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal You can check out my How-To (not sure how it works with latest Forrest version): http://wiki.cocoondev.org/Wiki.jsp?page=HowToForrestTransition snip / Please do, those will help, but for now, let's clear the whiteboard and start outlining the best publishing system. snip why=agree with outline / NOTE: from an operativity point of view, Pier has enough karma to setup everything we need on moof or nagoya, as well as providing accounts for those who want to help running the staging server (I would suspect Jeff and Steven to be interested in helping out, hopefully others as well). I volunteer. Thanks. Diana
Re: cvs commit: cocoon-2.0/src/java/org/apache/cocoon/transformation SQLTransformer.java
On Monday, March 10, 2003, at 06:45 AM, [EMAIL PROTECTED] wrote: Modified:lib jars.xml src/java/org/apache/cocoon/transformation SQLTransformer.java Added: legalLICENSE.jakarta-commons-lang lib/optional commons-lang-1.0.1.jar Carsten, My cvs update isn't showing the lib/optional/commons-lang-1.0.1.jar. So, in spite of your very thorough xmlutils bug fix -- many thanks -- cocoon-2.0 still isn't compiling for me based on this new bug fix. Diana
Re: cvs commit: cocoon-2.0/src/java/org/apache/cocoon/transformation SQLTransformer.java
On Monday, March 10, 2003, at 07:14 AM, Diana Shannon wrote: Carsten, My cvs update isn't showing the lib/optional/commons-lang-1.0.1.jar. So, in spite of your very thorough xmlutils bug fix -- many thanks -- cocoon-2.0 still isn't compiling for me based on this new bug fix. Diana My bad. I found a cvs configuration problem on my end. Diana
live site update complete
I updated the live site docs, with changes primarily reflecting the new cvs setup. A big thanks to Pier for the new cvs setup and **particularly** for making such a thorough update of all relevant docs in both 2.1 and 2.0 repositories. Diana
docs build exception, cocoon-2.0 repo
Has anyone been able to build cocoon-2.0 docs successfully? I'm trying to rule out a configuration problem on my end before digging deeper. (OS X, Java 1.3.1) I'm getting the following after ./build.sh docs docs: ERROR 2003-03-09 13:44:45.683 [] (): Could not load parser, Cocoon object not created. java.lang.ClassNotFoundException: org.apache.avalon.excalibur.xml.JaxpParser at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at org.apache.cocoon.util.ClassUtils.loadClass(ClassUtils.java:88) at org.apache.cocoon.Cocoon.initialize(Cocoon.java:256) at org.apache.cocoon.Main.main(Main.java:378) FATAL_E 2003-03-09 13:44:45.854 [] (): Exception caught org.apache.avalon.framework.configuration.ConfigurationException: Could not load parser org.apache.avalon.excalibur.xml.JaxpParser at org.apache.cocoon.Cocoon.initialize(Cocoon.java:259) at org.apache.cocoon.Main.main(Main.java:378) BUILD FAILED /Users/ds/cvs-apps/c2-release/cocoon-2.0/build.xml:1125: Java returned: 1 Thanks. Diana
Re: docs build exception, cocoon-2.0 repo
On Sunday, March 9, 2003, at 02:18 PM, Diana Shannon wrote: FATAL_E 2003-03-09 13:44:45.854 [] (): Exception caught org.apache.avalon.framework.configuration.ConfigurationException: Could not load parser org.apache.avalon.excalibur.xml.JaxpParser Reviewing Carsten's cvs commit http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=104696278122499w=2 it appears references to org.apache.avalon.excalibur.xml.JaxpParser are being phased out in other files. Trying javap -classpath `echo lib/core/*.jar | tr ' ' ':'` org.apache.excalibur.xml.JaxpParser Yields Class 'org.apache.excalibur.xml.JaxpParser' not found It appears the new excalibur-xmlutil jar uses org.apache.excalibur.xml.impl.JaxpParser The following files still contain references to org.apache.avalon.excalibur.xml.JaxpParser src/documentation/cocoon.xconf src/java/org/apache/cocoon/Constants.java src/java/org/apache/cocoon/cocoon.roles It isn't clear if these files also need to be updated or if the classes they refer to are merely deprecated (and need inclusion). So ... I'm unable to update the web site about the new repository changes until this is docs build problem is resolved. Any advice welcome. Diana
Re: CVS move/split...
On Saturday, March 8, 2003, at 05:46 PM, Pier Fumagalli wrote: Diane, can you roughly push the new site live tomorrow or Monday? You bet! Thanks Pier! Dian-a- ;-)
Re: Status of CVS Repositories Renaming
On Friday, March 7, 2003, at 01:44 AM, Bertrand Delacretaz wrote: ... Is there _anyone_ who knows how to rebuild and put live the site??? :-) :-) I can help, Pier. If someone can provide some modest language describing the new setup, I'll extend it and place it where appropriate in the xdocs. Then I'll update the live-site cvs and web site as appropriate. The update probably won't occur until Sunday. Diana
Re: [VOTE] bruno cvs commit rights
On Wednesday, February 26, 2003, at 09:17 AM, Morrison, John wrote: [EMAIL PROTECTED] seems to be doing an awful lot of coding atm, his patches look good and I can't see why he shouldn't be allowed to commit them himself! +1 Diana
Re: [VOTE:PMC] Proposal for Lenya as a Cocoon subproject
On Monday, February 24, 2003, at 06:01 PM, Nicola Ken Barozzi wrote: I'm asking the Cocoon PMC to vote for the inclusion of the below proposed project named Lenya (ex wyona.org) as a Cocoon subproject. This vote will take place on cocoon-dev where the Cocoon PMC lives. I'm CCing the incubator list just to notify that we're starting this vote. When finished, I'll post there the results. Cocoon PMC members, please state your votes. +1 Diana
Re: Writing docs... Where shall I put that?
On Tuesday, February 18, 2003, at 01:24 PM, Pier Fumagalli wrote: As Stefano is remodeling the build system, would it be better to have it in src/blocks/proxy/doc or in src/documentation/... I'd say src/documentation for now, in spite of its imperfections... Otherwise, the doc won't be published on the web. Also, users may not know to look for it in its block. I tend to believe that it might be better to have the documentation bundled together with the block, but then the build system for the webapp should change as well... I agree with you, but we can always refactor (move docs, etc.) down the road when better documentation build options become available/finalized. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Should we move mailing list names?
On Tuesday, February 4, 2003, at 02:16 PM, Pier Fumagalli wrote: As I've just done it for axis-dev, should we move the cocoon mailing lists from cocoon-(dev|user)@xml.apache.org to (dev|user)@cocoon.apache.org ??? Just don't forget cocoon-docs! Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HAPPY BIRTHDAY STEFANO!
On Tuesday, January 21, 2003, at 07:55 AM, Stefano Mazzocchi wrote: Thank you and happy birthday to all those born in January (so far, on this list, me, Sylvain, Ivelin, Pier, Jeremy... anybody else?) Me too, on Friday -- in the US, one of the more notorious -- 40 !! Definitely a cake torch! Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Michael Melhem as Cocoon committer
On Thursday, January 9, 2003, at 10:47 PM, Ovidiu Predescu wrote: I'd like to propose Michael Melhem as Cocoon committer. He has come up with lots of ideas for improvement in various parts of Cocoon including the control flow, and recently contributed an excellent patch for expiring continuations in the control flow layer. Becoming a committer will allow him to contribute his work more effectively. +1 Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Jeff Turner for cocoon committership
On Thursday, January 9, 2003, at 02:46 PM, Stefano Mazzocchi wrote: I hereby propose Jeff Turner for cocoon committership. He is one of the major forces behind Forrest and has been proposing important patches and features addition to the main Cocoon repository. +1 One of the many qualities of Jeff's work I admire is the way he documents it so thoroughly. Welcome! Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs sticky tag problem
On Wednesday, December 4, 2002, at 07:13 AM, Giacomo Pati wrote: Can you describe the steps you've taken until you got this error (essentially the commands you've issued where in which repo)? I maintain separate cvs directories for head and release files. After checkouts, I simply use: cvs -q update -d -P as needed. I don't like resetting sticky tags with -A because I'd prefer to keep the cvs versions separate. I live in a rural area with only a dialup connection, so checking out full cvs versions each time (as is sometimes recommended) is simply not efficient for me (i.e. that's why I prefer cvs updates). When I get into trouble, sometimes I delete the problematic directory, but it didn't help this time. In the src/documentation/xdocs/userdocs/actions/CVS I noticed that the text content for the Tag file is Ncocoon_2_0_3_branch as opposed to Tcocoon_2_0_3_branch as it is in other Tag files in other CVS directories. Thanks. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
release schedule and live site update
I had my fingers crossed that 2.0.4 might be released by today. However I understand the reasons for the delay. Starting today, I am traveling away from my office for the next seven to ten days and predict that I will have little, if any, time/bandwidth to update the live site. Therefore, I did the best I could yesterday and this morning, syncing common docs between branches, updating the live site cvs (both xdocs and javadocs), and updating the web site. Of course this isn't a **complete** release update for docs, but it's 99% of the effort involved. Clearly files like todo.html, changes.html, etc. will need to be updated once the release is official, but **any** committer can accomplish this in a spare minutes. For a refresher on how to do it: - Check out a version of the live site cvs (cvs.apache.org:/home/cvs/xml-site/targets/cocoon). - Add/commit your html files (from any release build). (Consider checking links with a third-party tool if you have concerns about the html files you are merging.) - Ask Carsten, Vadim, (or Steven?) to pull the updates to xml.apache.org. - Note: there are a few extra files in the live site cvs that are not in the release builds. These are redirects. Don't delete them. Thanks, and congrats to everyone on the release. Diana P.S. If anyone finds the above process primitive, well, **please** join the effort to prototype a Forrest transition for Cocoon docs. See: How-To Transition (will save you time getting up to speed): http://outerthought.net/wiki/Wiki.jsp?page=HowToForrestTransition Latest Transition Issues/Concerns: http://outerthought.net/wiki/Wiki.jsp?page=ForrestProposal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs sticky tag problem
I was trying to sync HEAD and release versions of src/documentation/xdocs/userdocs/actions/database-actions.xml but when I try to commit the updated version to the release branch, I get: cvs server: sticky tag `cocoon_2_0_3_branch' for file `database-actions.xml' is not a branch Any suggestions? Thanks. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Cocoon citizenship for Matthew Langham
On Thursday, November 28, 2002, at 06:19 AM, [EMAIL PROTECTED] wrote: Quoting Christian Haul [EMAIL PROTECTED]: On 27.Nov.2002 -- 10:19 AM, Stefano Mazzocchi wrote: All right. I hereby propose Matthew Langham for commit access. +1 (sorry for the late vote) +1 ..also being late;) +1 Also quite late, but quite happy to welcome a very deserving Matthew! Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Andrew Oliver commit access
On 22.Nov.2002 -- 12:42 AM, Stefano Mazzocchi wrote: I would like to propose Andrew Oliver for commit access. +1 A steadfast proponent for improved docs! Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Release Plan for 2.0.4
On Thursday, November 21, 2002, at 11:26 AM, Joerg Heinicke wrote: The most important bug seems to be the broken documentation (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12396), but I can't produce the bug on my system. There are now at least 3 people with the problem. Sorry, but I can't reproduce the bug either (Mac OSX 10.1 JVM 1.3.1). Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] build-time XML validation via RELAX NG
On Friday, November 15, 2002, at 12:21 AM, David Crossley wrote: [+1] Call 'validate-config' by default during the build. +1 Quite helpful! Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [important proposal] Cocoon as official Apache project
On Wednesday, October 30, 2002, at 08:29 AM, Stefano Mazzocchi wrote: +1 Hooray! Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Use Forrest to build Cocoon docs
I'm generally in agreement with Ken (in fact I proposed a separate CVS module for docs, powered by a Forrest webapp back in July on forrest-dev), but I agree with David that we need to clarify a number of key issues to make such a transition successful and efficient. While I haven't posted much recently on forrest-dev, I do keep up with the list. I'm also scrutinizing the latest cvs version and will have more comments soon. Here's a few issues that I have at this moment. 1. Is Forrest Ready? After all, it's still considered alpha, isn't it? I agree that docs need a stable framework for reliable generation, but at this point in time, I'd argue that the release branch of Cocoon is more stable than the current Forrest distro. Still, all of us are Cocoon-proficient and could most likely fix bugs caused by the use of the current alpha Forrest distro. Nevertheless, I would argue that such a transition **may** be a bit premature, unless we decide some kind of reliable update cycle for a distro that's still alpha (and that lacks any known release schedule). 2. What kind of docs and doc building facilities should we provide users? I agree with Ken that we it would be nice to move docs generation facilities and doc source files out of the code-oriented cvs branches. I think we should move them to a separate cvs module/branch that users can also download if they want to build docs locally. However, if users just want (prebuilt) docs, they should be able to download html files as they do nightly snapshots -- or something similar. Moving the docs out of the code branches does raise a few other issues. For example, we'd need to distinguish in docs builds between a web site build and a local docs build. Local docs can link to webapp samples (generated by the code cvs branches build), while a live site build cannot. 3. What is Forrest? Because Forrest is a Cocoon webapp, it's a bit unclear what distribution updates mean. It's not a simple issue like a few updated jars as is the case with most inter-project dependencies. The Forrest distro contains so many other files! For example, in the early days of Forrest, it wasn't clear if users were allowed to have their own sitemaps and sub-sitemaps. I don't think that's the case anymore, but I would like to get a better understanding of this. Still, even a few months ago, you guys were discussing the prospect of abandoning document-v11.dtd. How backwards-compatible can Forrest be at this early alpha state, and how easy would it be to fork Forrest unintentionally, like making some inappropriate edits to one of the distro files that later gets overwritten by a distro/cvs update? Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT] Getting rid of the table-based layout
On Saturday, October 19, 2002, at 09:17 AM, Geoff Howard wrote: Excuse my ignorance here, but isn't xml.apache.org still being served statically? You are correct. For the record, I updated the site earlier today. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
New Cocoon Committers
Dear Root, Please provide committer privileges to the Cocoon project to: Steven Noels ([EMAIL PROTECTED], [EMAIL PROTECTED] ) Bertrand Delacretaz ([EMAIL PROTECTED], [EMAIL PROTECTED]) These two individuals were recently elected with all +1 votes (14 total) by other Cocoon committers as shown in this thread: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=103421185605971w=2 Please note that both Steven and Bertrand already have a committer privileges with other Apache projects. Their Apache user ids are: Steven Noels: stevenn Bertrand Delacretaz : bdelacretaz Thanks very much. Diana Shannon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[vote] Steven Noels and Bertrand Delacretaz as committers
A recent discussion about a so-called documentation team prompted an offline discussion among some of us about the need for more documentation-oriented committers. As more and more users are getting involved with Cocoon documentation development via the lists, wiki, and even patches, it is critical to have receptive committers who can translate this effort into improved cvs docs. David Crossley and I would like to nominate two individuals who have repeatedly demonstrated their ongoing commitment to the Cocoon community, its documentation, and its code in the form of patches, participation, and leadership. They need no introduction but, for the record, they are: Steven Noels: indefatigable committer of the Forrest documentation project, generous host/facilitator/supporter of CocoonWiki and other valuable community resources at outerthought.net, strong advocate for a first-rate, Cocoon-based documentation system and associated best practices, and Cocoon community member for just over two years. Bertrand Delacretaz, founder and project leader of the jfor project (now distributed with Cocoon), committer to FOP project, Cocoon patch contributor, one of the earliest authors of docs for cocoon cvs and third party sites (www.cocooncenter.de), prolific CocoonWiki contributor, and Cocoon community member for just over one year. Thank you for your consideration. Diana Shannon David Crossley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: build docs broken in current 2.1-dev
On Tuesday, October 8, 2002, at 03:51 AM, David Crossley wrote: build docs seems to be broken in 2.1-dev or it is just mine (2.0.3-dev is fine). The debug messages do not seem to reveal issues. If you look in the logs, you will see that Cocoon is complaining about not finding the SVGSerializer. If you comment out references to it in the sitemap's map:components section, as well as to the matcher that uses the svg2jpg serializer, it will build for you. It worked for me yesterday. Is this related to Ken's mid-September efforts to move FOP and Batik classes to blocks? I'm not aware of a need for the SVGSerializer in the main docs. Should we delete these references in the documentation sitemap? Diana -- ... docs: Setup... done. Initializing... ready, let's go :-) * [0] - [broken link] index.html - disposing... done. BUILD SUCCESSFUL Total time: 18 seconds - ... oh no it is not. It did not get past the index.html --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Publication on cocoon
On Wednesday, September 25, 2002, at 03:50 AM, Carsten Ziegeler wrote: Ok, agreed. I only wanted to give a hint that most articles are already linked in the docs. I agree with Carsten's earlier point. Most articles have links within existing docs. BTW: What does our documentation team say to this? If someone really needs this doc -- to impress a boss/prospective client/IT manager -- then I suggest he/she create a patch. I promise to get it up on the live site quickly (in time for you to impress your boss/client/IT manager). Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Best way to start developing an application based on C2.1
On Wednesday, July 24, 2002, at 05:42 AM, Nicola Ken Barozzi wrote: Just a tip: if you install Cocoon jars in the WEB-INF/lib, you can add your classes in WEB-INF/classes, and just restart Tomcat to use the new classes. I do it also when developing Cocoon itself, since classes come before of the libs in the classpath. ;-) I received this helpful tip from Ivelin some time ago. Use a build target of webapp-local to generate classes (faster than a war build). Instead of restarting Cocoon, however, use Tomcat's manager to install a path to the updated webapp, e.g.: http://localhost:8080/manager/install?path=/cocoonwar=file:/cvs/c2-HEAD/xml-cocoon2/ build/cocoon/webapp When you make a change that requires another webapp build, remove the webapp: http://localhost:8080/manager/remove?path=/cocoon Then perform another webapp-local build and use the manager (as above) to install webapp again. A few other notes: - I typically disable all caching so I'm not sure if this works with caching enabled (i.e. without a clean work directory each time). - To get manager working, you need to make sure you have a manager context specified in server.xml - You need to add a user name=manager password=ZZZ roles=ZZZ / to tomcat-users/ in tomcat-users.xml Does anyone else use this? -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[release] site updated
Based on the status of 2.0.3 branch as of this am, the web site was updated. This includes javadocs (in spite of some warnings on build) and regular documentation. -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[samples] Results OS X, Java 1.3.1
Platform: Mac OS: OS X 10.1.5 Compiler: Pizza Results - I'm getting NPEs using the Lucene indexing page - http://localhost:8080/cocoon/hello.svg Still crops funny, but that's a OSX/Batik issue, IIRC... Suggestions - What database configuration is required for ESQL sample to work? http://localhost:8080/cocoon/xsp/esql We should make a note of it on that page like other database samples. - I thought Ken had already removed (ages ago) the sir from Are you being served, sir? on the link description at http://localhost:8080/cocoon/ based on a user remark. What about something like: How can I serve/help/assist you? -- Diana P.S. Thanks Konstantin for the recent patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [samples] Results OS X, Java 1.3.1
On Friday, July 12, 2002, at 07:42 AM, Diana Shannon wrote: Platform: Mac OS: OS X 10.1.5 Compiler: Pizza Sorry: JVM 1.3.1 Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote]: Applying patches
On Thursday, July 11, 2002, at 02:26 AM, Carsten Ziegeler wrote: Hi Team, I think we should vote on some patches we have in bugzilla. And here is the list of patches we could apply for 2.1-dev: 10429:[PATCH]ParameterSelector:new User doc, overview + examples Already applied against 2.1-dev and 2.0.3 yesterday. Sorry, I forgot to close it in Bugzilla. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Releasing 2.0.3?
On Thursday, July 11, 2002, at 06:35 AM, Carsten Ziegeler wrote: So, we need do to the following: a) Testing if everything works, espcially with regards to the different JVMs - I did a quick SQL test with both versions and they both worked. b) Update the documentation to include the jvm-target property etc. This should also go into the README c) Layout the distribution d) Check your docs for any 2.1-specific references and flag them (with note or similar). I may not get through each and every doc, so if you know the docs you have contributed have 2.1-specific content (either the doc as a whole or specific content within), please flag them as such. A while back, we decided on this list to sync HEAD and release docs to make it easier on committers working on docs. This included the provision that all 2.1-oriented docs would be noted to readers. I have added this info to a number of docs already, but I haven't concluded my general inventory of *all* docs. Any help would be greatly appreciated. I realize this is a bit of a manual hack, and I look forward to Forrest transition (coming soon) and solving this more elegantly, but I think the priority ATM should be user-friendly docs, however we achieve it. FYI, the only docs not synced remain changes.xml, todo.xml, sitemap.xmap, installing/index.xml, and installing/jars.xml. Ah, and finally a release date. If no problems or big bugs are found, I would propose monday, 15th of July. +1. Also, Carsten, let's include some language with the release notice about all the new docs accompanying it. We have *lots* of new content since 2.0.2. I'll provide a count if that helps! FYI: I'll update the live site for docs on Sunday if that works with this schedule. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Looking for help in the upcomming release
On Thursday, July 11, 2002, at 11:25 AM, Diana Shannon wrote: 5. Test *all* samples. Hit each and every sample page from links beginning at http://127.0.0.1:8080/cocoon/samples/ You're right, John. Going to ...cocoon/samples/ is incorrect. It goes to a 2.0.2-dev samples page. This was my mistake. I provided some of this draft to Carsten. Actually, the page says 2.0.2-dev but I think it's called the Refactored Samples, still a work in progress. These refactored samples *don't* need testing, correct? -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Looking for help in the upcomming release
On Thursday, July 11, 2002, at 11:18 AM, John Morrison wrote: 5. Test *all* samples. Hit each and every sample page from links beginning at http://127.0.0.1:8080/cocoon/samples/ You're right, John. Going to ...cocoon/samples/ is incorrect. It goes to a 2.0.2-dev samples page. This was my mistake. I provided some of this draft to Carsten. Assuming accessing via a servlet engine running on port 8080 (just for the pedantic ;) Where does http://127.0.0.1:8080/cocoon/ go to? Better. To the 2.0.3-dev samples welcome page. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: INSTALL file: small cleanup (for Diana)
On Thursday, July 11, 2002, at 11:35 AM, Enke, Michael wrote: Hi Diana, in section 3b) Manual install: [unix] ./build.sh -Dinclude.webapp.libs=yes -Dinstall.war=$TOMCAT_HOME/webapps webapp [win32] .\build.bat -Dinclude.webapp.libs=yes -Dinstall.war=%TOMCAT_HOME%\webapps webapp can be written without -Dinstall.war: [unix] ./build.sh -Dinclude.webapp.libs=yes webapp [win32] .\build.bat -Dinclude.webapp.libs=yes webapp I can't find any reference to this in installing-related content. Are you sure you have the latest release (or even HEAD) from CVS? -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
modules?
Is it correct to flag the userdocs/concepts/modules.html doc with the following note: Modules are only available in Cocoon 2.1 or 2.0.3 (with scratchpad libs). Thanks. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Question was: Re: [RT] reconsidering pipeline semantics
Can someone help fill in the holes below? On Wednesday, July 3, 2002, at 10:10 AM, Jason Foster wrote: We should really get this in a FAQ somewhere! What's the difference between having two pipelines with one matcher each, and one pipeline with two matchers? If there is no other difference in pipeline declarations, then none. Pipelines can differ by: - visibility: internal (not accessible for external requests) or normal - error handling: using different handle-errorss. - cachability (since 2.1): some requests can use cached responses from caching pipeline, while the others should not be cached, so you should use non-caching pipeline implementation - logical grouping: you can group logically related parts into separate pipelines Why? For ease of administrative/management concerns? Pipelines can also have an 'id', but I don't know how it's used, so you can have different 'id's for your pipelines. Any information about the intended purpose of id? Maybe I've forgot something, but this should be enough for understanding. Did he forget anything? Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Delaying the release?
On Tuesday, July 2, 2002, at 08:47 AM, Carsten Ziegeler wrote: Anyone still interested in a 2.0.3 release? Yes, but as we discussed off-list, I am counting on having until Monday of next week to update a number docs. I *really* need this additional time. Thanks for all your hard work in the cvs! Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [ANNOUNCE] actions and modules for flow
On Tuesday, July 2, 2002, at 06:45 AM, Stefano Mazzocchi wrote: Chris, I have another strong feeling: without at least a sample and a few lines of documentation about all this and what it is supposed to achieve, nobody will ever use it, nor even give you feedback. So I'd strongly suggest you to invest a few hours and provide them. I have *no* doubt Chris will provide excellent docs, given his ongoing track record. Within hours of the recent input module source commits of Sylvain, Chris had updated modules.xml accordingly. Chris' docs related to databases were noted by users as being great. From what I have seen, in my short time observing the cvs, he keeps his docs up-to-date and provides a great example for others. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Delaying the release?
On Tuesday, July 2, 2002, at 09:22 AM, Vadim Gritsenko wrote: Lots of users. I'm, as developer, can work with CVS. Lots of the users can't. I think this is an education issue which can be addressed down the road. Many users don't understand why -- i.e. the benefits of using cvs. IMHO, the how can be easily taught by extending existing instructions in contrib.xml into a full-fledged How-To... Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Delaying the release?
On Tuesday, July 2, 2002, at 10:16 AM, Vadim Gritsenko wrote: I'm, as developer, can work with CVS. Lots of the users can't. I think this is an education issue which can be addressed down the road. AFAIU the issue, this is the point in 20% of cases. Even if true, 20% equals a lot of users... Other 80% is politics Sure, but educating the 20% may help change the politics as well, over time. (it was hard enough to persuade usage of open source, and now you have to explain that you need to use unreleased version?), I wouldn't say need to use (as in *required* to use). I would simply try to communicate some of the benefits to learning/using an unreleased version... So much of my conceptual education about Cocoon comes from discussions on cocoon-dev. If I didn't have the HEAD cvs, how could I begin to follow/appreciate these threads? Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT]: One step for a minimal Cocoon
On Monday, July 1, 2002, at 04:46 AM, Piroumian Konstantin wrote: This is already done for the scratchpad and would be fine also for the samples. The only problem is that you'll need also some additional info, e.g. a short description, for the sample. I've proposed to add a 'map:description' top-level element to sitemap, which can be used to generate that info. -1 IMO this breaks SoC. Another idea is the have a sample.xml document in each sample directory, that can be processed by the XPathDirectoryGenerator to get the needed description from it. +1 Then we can expand such a file in the future to include more that a short description. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RT]: One step for a minimal Cocoon
On Monday, July 1, 2002, at 07:36 AM, Piroumian Konstantin wrote: For simple samples (e.g. 'hello world', 'svg') this file can be the front-page, and then it's worth it. But the samples with their own layout and styles would like to have their own front-page (i18n, flow). So, I'd like to use a description from the sitemap for the page with the samples list and samples should provide a default matcher displaying the desired front-page. If you explain what else can be added to the sample.xml document except a short description then I'll change my opinion. We still need to treat (and manage) samples consistently (from a CMS point of view), regardless of their internal skins -- or even front page. Dynamic samples may need to be managed similarly to static documents. You may need to add - short as well as long description content (i.e. with block elements) - implementation-specific info (some of the *same* samples have slightly different implementations, based on where they are located, e.g. 2.0.3 versus 2.1) This is critical info, IMHO. - versioning info (when samples change, users may want to know. I know *I* do) - topic info (so you can add links to samples from static docs in a How-To or tutorial, or some other doc ... ) - component dependencies (what needs updating when something in source changes) - targeted user info (beginner, intermediate, advanced) etc. etc. etc. Does this help to convince you of the need? -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[doc] policy for authorship credit
I need your input on how to think about bylines Cocoon docs, both community-contributed and core docs (soon to be patched by new volunteers). I'm struggling to understand how to credit the efforts of people who make the docs better. This effort doesn't always equate to authorship, that is, you can spend hours editing a doc (I have) but not necessarily contribute a substantial amount of new content. Still, the doc is better as a result of your effort. I also want to avoid problems down the road when users patch docs and add their name as an author, even when they may have only contributed a single sentence. In other words, I want to reward bylines to people who take the first step of authoring a new doc or who add substantial amounts of additional content. Writing is hard. Patching (what someone else started) is often a lot easier. Example: lots of patches were submitted for XMLForm How-To. No patches yet for new How-Tos. Forrest introduces a revision content section. I like it. For an example, check out this document and look at the revision history section (at the bottom of the page): http://xml.apache.org/forrest/primer.html I think crediting individuals (committers as well as volunteers) for their patches in a Revision History section -- and not necessarily in the byline area, unless they are a co-author or add significant amounts of new content -- is the best way. It also serves as a meaningful record for users about updates to docs (i.e. how many users check cvs log info?). Some users have the mistaken understanding that core docs aren't being updated. This would demonstrate to them clearly what is going on. It would also visibly reveal documents which may need to be updated. I experimented with this approach in the How-To I created for the Paginator Transformer. I didn't write it originally, Stefano did on this list, so I gave him credit in the byline. However, I put a lot of time editing, restructuring, testing, debugging, adding samples, etc. so I noted my work in the revision section. Stefano has since updated the samples, so I will add another item to the revision section, noting his work. When users start reading the How-To, perhaps they will begin to appreciate the effort that goes into creating a good doc... Although I really don't like bylines at all in this context, especially for core docs, I think we need to keep them as an incentive for new authors to contribute docs (i.e. get rewarded with some visibility for their effort). It also gives them the incentive to maintain their contribution, because their name is publicly associated with the work. What do you think? -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [doc] policy for authorship credit
On Monday, July 1, 2002, at 08:44 AM, Steven Noels wrote: We could add some (non-required) CMS revision elements/attrs to the documentheader element and generate the revision history automatically at the bottom of the page. An idea for Forrest, perhaps? Yes, of course. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: docs misc
On Thursday, June 27, 2002, at 02:34 AM, Mikhail Fedotov wrote: After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Two things to mention: 1. I've been talking here about documentation in form of dictionary, where is no structure and long docs, just complete descriptions of components and their parameters; it is the quick way to produce complete components documentation that helps in creation of more complex documentation. If someone will become interested in lowering the difficulty of writiting docs (that I've been talking about), and not just writing another docs page (that I've been told to do as an response), he could arise that topic again. Well why don't you check out wiki dictionary effort made with Cocoon? Perhaps you could help build that dictionary. http://www.anyware-tech.com/wikiland/ 2. About the current docs. They aren't _that_ bad, there is much of information. But it looks more like an student work, i.e. it gives impression of work made, but not optimized for easy understanding and using. Try not to jump to conclusions about why the state of documentation is what it currently is. I made that mistake earlier on this list. ;-) I continue to learn new factors almost every day why producing good docs is difficult in this context. I could add a hundred items to your list. Think of the quality of docs as an indicator of a community's evolution. When more people come forward to help improve existing docs, and contribute new docs, then they will improve. No sooner and no later. If this keeps Cocoon from reaching new audiences, then that's just a result -- it isn't necessarily a problem, just a phase of growth. There is an effort at Apache Forrest to improve underlying documentation architecture. If you don't want to contribute new/revised docs to the Cocoon project, perhaps you'd be interested in supporting that project's architectural efforts? http://xml.apache.org/forrest/ Here is one good model usable in too much contexts to mention, and it is also good in writing docs: I have built a lot of models in my professional life, and I'm not sure I would be so brave as to model open source community dynamics ... ;-) snip / Symptoms - complex webapp, many documents, big hierarchy, difficulties with all this; some paragraphs about it. I don't agree that a complex webapp is a symptom of a problem. I think the problem that Cocoon is trying to solve is complex. As for many documents, I agree some could be refactored however isn't going to happen until Cocoon migrates to a Forrest architecture (in process already). At the point, many more options to improve the docs structure will become available to us. It just takes time when everyone is a volunteer. We are also making the best of available resources, which at the present time, includes a static web site. Still, I prefer more docs. I don't think there are too many docs. I also want to increase the author pool. With difficult, complex subjects like Cocoon, sometimes you need multiple voices to say the same thing, just a bit differently. When you are learning something new, and you have the luxury of buying books, wouldn't you prefer to buy more than one, even if it's about the same topic? Causes - hierachy isn't structured, components dependence is out-of-control, bad code reuse, too much amount of everything, etc; some paragraphs about it. Outcome - doing things in a more structured way; some paragraphs about it. You can have all the structure in the world but you still need writers. IMHO, the hardest part is writing well. If we make writing easy by removing so-called architectural obstacles, does that mean we'll automatically have good content? I'm not sure about this. Don't get me wrong, I think architectural improvements will help immensely. However, you probably are aware that many authors have the additional challenge of having to write in a non-native language. Regardless of what you think about the docs, I really admire the people who have contributed docs so far. And I'm also excited about the books coming out. Resources - use of SoC pattern with Cocoon2 as a tool, transforming the hierarchy into tree with no dependency between branches; some paragraphs about it. What do you mean by hierarchy? The documentation hierarchy? If you are concerned about 2.1 docs being made available with 2.03 docs, then isn't it enough to note, in very clear and visual terms, what content applies to what branch? The 2.1 docs we have are very good. I think they help users understand some of the great stuff that is going on in the HEAD branch. As long as they are warned, I don't see the problem. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: Samples from HEAD broken?
On Thursday, June 27, 2002, at 01:00 PM, Enke, Michael wrote: Stephan Michels wrote: Hi, I noticed that the samples doesn't work anymore? I think the reason are the changes for the bug://10277 (mime-type). Long time ago I noticed the same and Diana Shannon wrote that there is a patch but nobody has time to apply it :-( I don't think I made this statement. I too have noticed the problem, in HEAD and release, for samples included under webapp/mount/ only today. I've been working with samples in both areas for a few days now (with frequent updates) so it appears to be relatively new issue. Out of time to troubleshoot ATM... -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)]
On Sunday, June 23, 2002, at 12:25 PM, Daniel Fagerstrom wrote: snip / So what use cases do we have? * It should definitely be easy to write wizards in a flow description language. I believe this is the case for flowscripts (see http://marc.theaimsgroup.com/?l=xml-cocoon-devm=102052662705449w=2, for details), but on the other hand this could be done in a much smaller and more specialized language. Ivelin and Torsten listed some requirements for wizards, IIRC. * Shopping carts? This will be possible when Ovidiu (or someone else) have added variables that are accessible across different flowscript invocations. * Anything more? I'm trying to imagine what it would be like to use the same sitemap (view) and same content (model) with different flowscripts. Here's some *very* preliminary thoughts on how I might apply flowscripts to a real world need (based on an even more preliminary understanding of what might be possible). Use Case Idea 1 what: games, simulations, decision support webapps model: e.g., simulation model of an ecosystem - view: sitemap pipelines, presenting useful views of ecosystem (status, history, impacts, etc.) - controller: flowscripts - flowscript variations - different webapps (a) single-user simulation game (users interact with model over a period of time) (b) multi-user game, similar to (a) but different players (characters with different roles) had different flow scripts (c) simulation tool (not a game) which shows results of policies over time (d) decision support tool with feedback about policy decisions (flowscripts could be even be granularized based a a field of concern, e.g. a farmer may want different advice than a logger) ... Note: I know you're probably thinking, these all could use different views (sitemaps) as well. While this may be true, in my experience, there is a lot of view overlap among these seemingly different applications. Use Case Idea 2: what: learning tools model: learning content view: document pages, quiz pages, feedback pages, report pages, etc. controller: flowscripts - same tools, different audiences and users with varying learning levels (a) basic, intermediate, advanced flowscripts (or grade-level, professional concern) for different levels of ability (Some learners need reinforcement when they struggle with concepts, other don't.) This could be dynamically generated, of course. (b) different flowscripts based on context of use (how much time available, professional needs, etc.) (c) different flowscripts (for future continuations) generated dynamically (or by a teacher, e.g.) based on a student's past performance. On the other hand, once you have a great set of flowscripts, you could use them with different sitemaps and different models as well. With SoC, the possibilities seems almost unlimited for extremely valuable reuse. Is this overkill for a flowscript? Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
run.sh/command line issues
I am working on a How-To for the command line. To get started, I had to deal with a few issues described below. First of all, I just committed a patch for run.sh which now reflects the revised lib directory structure of 2.03 and HEAD. (Note that run.bat already reflects the correct directory structure.) To test, I typed: ./run.sh -help in both 2.03 and 2.1 branches. This worked on my setup (OSX 10.1, Java 1.3.1). Please crosscheck on other Unix flavors. I then performed a command line static build. I simply did a regular docs build (./build.sh clean docs), deleted the html files in /build/cocoon/docs and then ran ./run.sh -c build/cocoon/documentation -C build/cocoon/documentation/cocoon.xconf -d build/cocoon/docs -w build/cocoon/work index.html This worked on 2.03, but it failed on 2.1. From the logs, it looks like the context directory flag (-c) is received: DEBUG 2002-06-15 11:54:21.183 [ ] (): Getting handle to destination directory 'build/cocoon/docs' DEBUG 2002-06-15 11:54:21.365 [ ] (): Getting handle to working directory 'build/cocoon/work' DEBUG 2002-06-15 11:54:21.368 [ ] (): Getting handle to context directory 'build/cocoon/documentation' However, later on in the log, it appears the context is not resolved correctly. DEBUG 2002-06-15 11:55:42.831 [manager ] (): Resolving 'sitemap.xmap' with base 'null' in context 'file:/Users/ds/cvs-apps/cvs-HEAD- c2/xml-cocoon2/' DEBUG 2002-06-15 11:55:42.833 [manager ] (): Resolved to systemID 'file:/Users/ds/cvs-apps/cvs-HEAD-c2/xml-cocoon2/sitemap.xmap' DEBUG 2002-06-15 11:55:42.857 [manager ] (): Making URL from file:/Users/ds/cvs-apps/cvs-HEAD-c2/xml-cocoon2/sitemap.xmap ERROR 2002-06-15 11:55:42.895 [sitemap ] (): Failed to load sitemap from file:/Users/ds/cvs-apps/cvs-HEAD-c2/xml-cocoon2/sitemap.xmap org.apache.cocoon.ResourceNotFoundException: Resource not found.: org.apache.excalibur.source.SourceNotFoundException: Resource not found file:/Users/ds/cvs-apps/cvs-HEAD-c2/xml-cocoon2/sitemap.xmap When I changed the path to sitemap file in build/cocoon/documentation/cocoon.xconf from sitemap file=sitemap.xmap check-reload=yes logger=sitemap/ to make it relative to run.sh (still sitting in the root cvs directory) sitemap file=build/cocoon/documentation/sitemap.xmap check- reload=yes logger=sitemap/ it worked with 2.1. Should I file this as a bug? -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [doc] links in misc. emails
On Wednesday, June 12, 2002, at 04:04 PM, Stefano Mazzocchi wrote: Diana Shannon wrote: 1. How can we change the FAQ pointer, a signature on cocoon-user emails, to point to the new FAQ location: http://xml.apache.org/cocoon/faq/ Hmmm, I really don't know. You might want to ask to [EMAIL PROTECTED] (which is the people taking care of the ASF mail infrastructure) Pier already fixed this. :-) Thanks. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XMLForms and Flowmap
On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote: Feel free to ask if you need further clarification about my integration proposal. What *I'm* most interested in is a statement you made a while ago on this list about the difficulties students can have learning about continuations, from your direct experience teaching continuations. Do you have any suggestions for the doc effort in this regard? In what aspects do students have problems: understanding the concept, applying them to real-world situations, etc.? I've read up on continuations, generally, but so many existing docs are tied to Scheme implementations (which could frighten users, as has also been discussed). Can you point to any existing teaching resources that you use? Care to donate anything of your own, even a teaching outline? Any tips? Look how much attention XMLForm has already received, simply as a result of the XMLForm Wizard How-To being published to release and live site, announced, etc. ... If anyone feels their work/component is languishing in HEAD, please reconsider what a focused, user-friendly How-To can do for it. If you need help writing, contact me. Perhaps we can set up team writing efforts. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Cocoon dictionnary.
On Thursday, June 13, 2002, at 08:06 AM, Steven Noels wrote: we would be able to host this. Great news, Steven. this seems however like a core documentation effort. Could you please synchronize your efforts with Diana's and Forrest's? The last thing we want to happen is the documentation effort being fragmented. If we work separately: fragmentation and diminished overall value to users. If we work together: the sum is greater than the parts, i.e. value-added for users. My hopes: 1. That wiki results (from any wiki effort, not just a dictionary one) can be harvested, edited, and incorporated into core Cocoon docs on a periodic basis. This helps the user experience by saving time (when they lack time to navigate though wiki-like stream-of-consciousness posts, just to find a definition.) It also facilitates i18n efforts. In other words, I want the effort to be owned by the community, in the fullest sense, so it can be used for other documentation/learning tool needs, without restriction. 2. That developers provide some feedback. I too am seeing a lot of confusing issues over descriptions of components behavior within existing docs. I think this is due, in part, to the Java object model not always having direct analogies to the user experience (which may not include examining the code for answers). One example (there are many others like this): 1. Quote: http://xml.apache.org/cocoon/userdocs/generators/extractor-generator.html FragmentExtractor is a transformer-generator pair which is designed to allow sitemap managers to extract certain nodes from a SAX stream and move them into a separate pipeline. The main use for this is to extract inline SVG images and serve them up through a separate pipeline, usually serializing them to PNG or JPEG format first. Questions a new user may ask: Sitemap manager: Is this a person or a Cocoon component? Separate pipeline: Where/what is this separate pipeline? But what if I have only one pipeline declared in my sitemap? 3. That we implement, when possible, an XML-based approach/implementation of wiki, to facilitate integration with Forrest documentation architecture. -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some broken links in http://localhost:8080/cocoon/samples/welcome
On Thursday, June 13, 2002, at 10:03 AM, Enke, Michael wrote: -All links in More Samples (except Portal and Authentication) are broken. -Scratchpad sample doesn't work -Slides link (Documentation) is broken -Documentation (Form Handling) is broken -Control Flow: If I follow the links, the page looks buggy: The menu is overwritten by a white empty box -Request Page (System Tools and Pages) gives back a xml document (and not html) -Status Page (System Tools and Pages) has no values, only the headings A *number* of these problems are fixed by recent patches submitted via Bugzilla by Andrew Savory. I'm sorry I haven't had time yet to apply them as I'm buried with non-Sample documentation work in progress. Anyone else available to apply Andrew's timely contributions? Ivelin, there are fixes for FormHandling sample which you may want to review. -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AcceptSelector
On Wednesday, June 12, 2002, at 01:30 PM, Michael Hartle wrote: How should I provide the source code so you can check it out? (I'm new to cocoon-dev.) This sounds interesting, so just go to Bugzilla and add it as a bug for Cocoon 2, prefixing your Summary with [PATCH] and adding your code as a zipped attachment; that way, anyone is able to check out your code, it will be listed in the regular Patch mail to the cocoon-dev list and if there are no objections, your addition can be added to the CVS by a committer who has the time to do so. For an example of such a [PATCH] bug for Bugzilla, see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9404. To file your patch, go to http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Cocoon%202. You will have to create an account, but this goes fast and doesn't hurt ;) Please check out Cocoon's fine How-To, written by our very own David Crossley: http://xml.apache.org/cocoon/howto/howto-bugzilla.html Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[doc] Call for doc contributors!
[FYI: sorry for xpost] Did you know you can help improve Cocoon's documentation? Right now, in the most recent CVS release branch and on the live site, you'll find the resources you need to contribute new FAQs, How-Tos, and Code Snippets to the Cocoon project. Specifically: How to author an FAQ (or set of FAQs) http://xml.apache.org/cocoon/howto/howto-author-faq.html How to author a How-To http://xml.apache.org/cocoon/howto/howto-author-howto.html How to author a Code Snippet http://xml.apache.org/cocoon/howto/howto-author-snippet.html How to submit your contribution via Bugzilla http://xml.apache.org/cocoon/howto/howto-bugzilla.html How to submit your contribution as a Patch http://xml.apache.org/cocoon/howto/howto-patch.html We are taking a deliberately granular approach to facilitate contributions from the widest range of Cocoon users. For example, once guidelines are written, we will announce other types of documents you can also contribute: Recipes, Success Stories, Tutorials, Live Examples, etc. In other words, this is only the *beginning* of a new, community-oriented approach to documentation development. Cocoon is an immensely sophisticated piece of software. At times, however, we all know it can be difficult to grok certain aspects of it. Thus, the more voices that help to explain Cocoon, the better for everyone. Carve out a niche for yourself as an author. If your contribution is useful to others, it will be published the Cocoon's web site! Just as Cocoon provides endless possibilities to build cool stuff, it also affords us an unlimited amount of creative space to write about it. Take a minute to imagine how advanced the Cocoon community would become if each and every Cocoon user took the time to contribute a single, unique FAQ, How-To, or Snippet. Think about it. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[doc] links in misc. emails
1. How can we change the FAQ pointer, a signature on cocoon-user emails, to point to the new FAQ location: http://xml.apache.org/cocoon/faq/ 2. Could we add links to the Bugzilla and Patch How-Tos within the autogenerated PATCH QUEUE email? If so, here is some proposed language. patch HOWTO Send patches to http://nagoya.apache.org/bugzilla/ specifying [PATCH] in the summary. For more information on submitting a patch, read: http://xml.apache.org/cocoon/howto/howto-patch.html Bugzilla sends a mail automatically to this list. Reviewers will mark it FIXED there when applied. Patches not sent to Bugzilla will not be reviewed. For more information on using Bugzilla, read: http://xml.apache.org/cocoon/howto/howto-bugzilla.html -- Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[doc] live site update report
I just updated (with the help of Vadim on xml.apache.org) the live site. It is now synced with the release and HEAD branch docs with the exception of a few docs in src/documentation/xdoc/developing/. Carsten (or someone else) will have to inform me about a few issues there. One way to get some sense the changes is to view the edited diff (provided below) between HEAD and release branches, which I did before I synced HEAD and release docs. This of course doesn't capture updates other committers may have made last week to the release branch (which are *greatly* appreciated). Diffs of html files (between the release build and the live site repository) are misleading. Simple navigational changes within a section menu will impact *all* files in that directory, suggesting changes which aren't substantively relevant. I will announce the doc effort publicly on both cocoon lists on Monday. -- Diana new src/documentation/stylesheets/faqcommon.xsl src/documentation/xdocs/faq (plus many individual files) src/documentation/xdocs/howto (plus many individual files) src/documentation/xdocs/snippet (plus many individual files) src/documentation/xdocs/tutorial (plus many individual files) src/documentation/xdocs/ctwig/ctwig-osx.xml src/documentation/xdocs/installing/updating.xml src/documentation/xdocs/userdocs/serializers/xls-serializer.xml modifications src/documentation/sitemap.xmap src/documentation/stylesheets/book2menu.xsl src/documentation/xdocs/book.xml src/documentation/xdocs/index.xml src/documentation/xdocs/mail-lists.xml src/documentation/xdocs/who.xml src/documentation/xdocs/ctwig/book.xml src/documentation/xdocs/ctwig/ctwig-installing.xml src/documentation/xdocs/ctwig/ctwig-resources.xml src/documentation/xdocs/developing/book.xml src/documentation/xdocs/installing/book.xml src/documentation/xdocs/installing/index.xml src/documentation/xdocs/installing/jars.xml src/documentation/xdocs/link/books.xml src/documentation/xdocs/link/tips-guides.xml src/documentation/xdocs/plan/changes-doc.xml src/documentation/xdocs/plan/todo-doc.xml src/documentation/xdocs/userdocs/index.xml src/documentation/xdocs/userdocs/actions/actions.xml src/documentation/xdocs/userdocs/concepts/databases.xml src/documentation/xdocs/userdocs/concepts/sitemap.xml src/documentation/xdocs/userdocs/generators/directory-generator.xml src/documentation/xdocs/userdocs/generators/error-generator.xml src/documentation/xdocs/userdocs/generators/file-generator.xml src/documentation/xdocs/userdocs/generators/generators.xml src/documentation/xdocs/userdocs/generators/jsp-generator.xml src/documentation/xdocs/userdocs/matchers/matchers.xml src/documentation/xdocs/userdocs/selectors/selectors.xml src/documentation/xdocs/userdocs/serializers/book.xml src/documentation/xdocs/userdocs/serializers/serializers.xml src/documentation/xdocs/userdocs/transformers/i18n-transformer.xml src/documentation/xdocs/userdocs/transformers/transformers.xml deletions (refactored elsewhere) src/documentation/xdocs/faq.xml src/documentation/xdocs/tutorial-shots.xml src/documentation/xdocs/tutorial.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [doc] live site update report
On Saturday, June 8, 2002, at 12:43 PM, John Morrison wrote: Diana, How did you build the files? http://xml.apache.org/cocoon/installing/jars.html To clarify, I sync all docs in head and release branches below src/documentation/xdoc. Then I perform ./build.sh clean docs within the release branch xml-cocoon2 directory. isn't correct. This should have been replaced by the file generated by check-jars... How is this generated? Diana J. -Original Message- From: Diana Shannon [mailto:[EMAIL PROTECTED]] Sent: Saturday, 8 June 2002 5:32 pm To: [EMAIL PROTECTED] Subject: [doc] live site update report I just updated (with the help of Vadim on xml.apache.org) the live site. It is now synced with the release and HEAD branch docs with the exception of a few docs in src/documentation/xdoc/developing/. Carsten (or someone else) will have to inform me about a few issues there. One way to get some sense the changes is to view the edited diff (provided below) between HEAD and release branches, which I did before I synced HEAD and release docs. This of course doesn't capture updates other committers may have made last week to the release branch (which are *greatly* appreciated). Diffs of html files (between the release build and the live site repository) are misleading. Simple navigational changes within a section menu will impact *all* files in that directory, suggesting changes which aren't substantively relevant. I will announce the doc effort publicly on both cocoon lists on Monday. -- Diana new src/documentation/stylesheets/faqcommon.xsl src/documentation/xdocs/faq (plus many individual files) src/documentation/xdocs/howto (plus many individual files) src/documentation/xdocs/snippet (plus many individual files) src/documentation/xdocs/tutorial (plus many individual files) src/documentation/xdocs/ctwig/ctwig-osx.xml src/documentation/xdocs/installing/updating.xml src/documentation/xdocs/userdocs/serializers/xls-serializer.xml modifications src/documentation/sitemap.xmap src/documentation/stylesheets/book2menu.xsl src/documentation/xdocs/book.xml src/documentation/xdocs/index.xml src/documentation/xdocs/mail-lists.xml src/documentation/xdocs/who.xml src/documentation/xdocs/ctwig/book.xml src/documentation/xdocs/ctwig/ctwig-installing.xml src/documentation/xdocs/ctwig/ctwig-resources.xml src/documentation/xdocs/developing/book.xml src/documentation/xdocs/installing/book.xml src/documentation/xdocs/installing/index.xml src/documentation/xdocs/installing/jars.xml src/documentation/xdocs/link/books.xml src/documentation/xdocs/link/tips-guides.xml src/documentation/xdocs/plan/changes-doc.xml src/documentation/xdocs/plan/todo-doc.xml src/documentation/xdocs/userdocs/index.xml src/documentation/xdocs/userdocs/actions/actions.xml src/documentation/xdocs/userdocs/concepts/databases.xml src/documentation/xdocs/userdocs/concepts/sitemap.xml src/documentation/xdocs/userdocs/generators/directory-generator.xml src/documentation/xdocs/userdocs/generators/error-generator.xml src/documentation/xdocs/userdocs/generators/file-generator.xml src/documentation/xdocs/userdocs/generators/generators.xml src/documentation/xdocs/userdocs/generators/jsp-generator.xml src/documentation/xdocs/userdocs/matchers/matchers.xml src/documentation/xdocs/userdocs/selectors/selectors.xml src/documentation/xdocs/userdocs/serializers/book.xml src/documentation/xdocs/userdocs/serializers/serializers.xml src/documentation/xdocs/userdocs/transformers/i18n-transformer.xml src/documentation/xdocs/userdocs/transformers/transformers.xml deletions (refactored elsewhere) src/documentation/xdocs/faq.xml src/documentation/xdocs/tutorial-shots.xml src/documentation/xdocs/tutorial.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [doc] live site update report
On Saturday, June 8, 2002, at 12:54 PM, Diana Shannon wrote: isn't correct. This should have been replaced by the file generated by check-jars... How is this generated? It's not a build target for the release branch. Is it ok to include the result generated for HEAD on the live site? Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [doc] live site update report
On Saturday, June 8, 2002, at 12:49 PM, Andrew Savory wrote: Question: should the documentation on the site reflect HEAD, the stable development branch (2.0.3-dev), or the latest stable release? I'd suggest either of the latter two, as most people I assume will be using the stable release, and will expect stable documentation to go with it? I'm adding notices at the top of any doc related to 2.1. It's the same notice that appears in the WARNING note in the 2.1 branch. It's impossible, otherwise, to manually keep the branches in sync. You'd have different book.xml files, etc. I'm afraid it would introduce too many other problems. There aren't too many 2.1 docs, right now, only a handful. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [doc] live site update report
On Saturday, June 8, 2002, at 01:41 PM, Andrew Savory wrote: I'm adding notices at the top of any doc related to 2.1. It's the same notice that appears in the WARNING note in the 2.1 branch. Ah, that makes a lot of sense, and should help keep track of new features etc for people upgrading from older versions. RT: maybe it's worth flagging versions (eg Since: 2.0.1 or Since: 2.1) on new documentation (or documentation about new features)? Although I guess the changelog is used for this, too... No, it's not a RT at all, you're quite on target. It would be nice to include meta info in documents which relate to any component/version dependencies. It would be nice to automatically flag (during transformation) any doc which was last checked against an alpha or old release. This will inform/alert users (until an author/editor/reviewer could update the content and/or last checked status). FAQs, in particular, get out of date rather quickly. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [doc] live site update report
On Saturday, June 8, 2002, at 12:43 PM, John Morrison wrote: How did you build the files? I built from the release branch, once I synced docs from head. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FW: faq on cocoon-homepage
On Saturday, June 8, 2002, at 02:51 PM, Pier Fumagalli wrote: Hi! [ http://xml.apache.org/cocoon/ ] The links to the faq section are linked wrong. They point to faq.html, but it's faq/ Regards, Daniele I'm not sure what links she's referring to, but Vadim astutely pointed out the reference to faq.html at the bottom of each and every cocoon-user email. I've added a redirect page for faq.html (points to faq/index.html) to the live site repository. Now I need Vadim to update the web site, one *last* time... ;-) Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FW: faq on cocoon-homepage
On Saturday, June 8, 2002, at 09:49 PM, Diana Shannon wrote: [ http://xml.apache.org/cocoon/ ] The links to the faq section are linked wrong. They point to faq.html, but it's faq/ Regards, Daniele I'm not sure what links she's referring to, but Vadim astutely pointed out the reference to faq.html at the bottom of each and every cocoon-user email. I've added a redirect page for faq.html (points to faq/index.html) to the live site repository. Now I need Vadim to update the web site, one *last* time... ;-) Diana Actually, Carsten (thanks!) just added a redirect for faqs.html (still listed at the bottom of cocoon-user emails), and I added a redirect (just got my privs working) for faq.html, which was the old link, noted above by Daniele. Do we really need to add redirects for all moved docs? I understand the need for faq, etc., but what about recently moved (and very recently committed docs) like xmlform-wizard tutorial? This may be a PITA to manage down the road, especially if we refactor some of the core docs, now spread across several guides. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Wiki documentation system
On Friday, June 7, 2002, at 05:37 AM, Jeremy Quinn wrote: If we had something similar to BugZilla for documentation, that would accept emailed doc updates, then the work of the editor could take place on the servers set up by the users, and posted to the Doc BugZilla for checking and if appropriate, inclusion. The documentation pages could be rendered (on users machines) with links that allow users to bring up a form to add comment|add patch|etc. This form would be processed on their own server, then sent in to Doc BugZilla. Agreed. IMO, you'd need to accept both comments (small amounts of text added to the bottom of a document) and doc revisions (changing existing content). Comments don't require as much technical or editorial review to decide relevancy. Revisions may sit in Bugzilla for a while. I submitted a sample of how we could handle comment submissions to Forrest (within a larger community contribution framework) on the server. Once it's in Bugzilla, the comment file is simply added to the directory of the document in question. A naming convention associates it with the document. A pipeline with a directory generator discovers the association and adds links to such comments at the bottom of the document in question. It makes it easy for committers to just throw comment files into document directories. Ken made the suggestion we could add a form (simplified Bugzilla interface) to add the ability to collect comments on the live site (as well as in the distro). You'd need to log in to Bugzilla, and come back, prior to submitting, of course. Still, revisions which impact the whole document could be tricky absent the locking associated with tradition CMS. How would you handle multiple, simultaneous revisions (impacting the whole file, not just a comment) made to the same document? Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Cocoon article on JDJ
On Friday, June 7, 2002, at 12:56 PM, Mikhail Fedotov wrote: We are perfectly aware of the issues with documentation ...and I'm aware that you are aware of it, sorry for bothering. :) But... and we are moving as fast as we can to improve things, believe me, also along with the forrest effort. I'm pretty sure that things will be better in time and the fact that more and more articles come up is a pretty good sign of it anyway. ...but I wanted to say that if there will be _simple_ standardised way to document _anything_ in Cocoon in the same manner (no matter if it is db action or xsp logicheet), we can create simple encyclopedy with short descriptions for all basic and advanced cocoon2 elements, and things will more faster. I think it would be highly reasonable to create alphabetic dictionary of all cocoon elements no matter there they belongs with short descriptions of them. It should be very easy to maintaint it, that's why it is a good thing. This seems to be an important point - if there will be easy way to create simple and short documentation, more people will write it, and there will be more documentation. I agree. So why not start *now*. In head and release branches already, and coming soon on the the live site, you will find everything you need to make a simple and short but very valuable contribution to Cocoon docs. Contribute an FAQ, a Code Snippet, a How-To. They are deliberately granular, designed to serve as building blocks for more sophisticated content later. You'll find How-To instructions on how to do everything -- authoring, patch preparation, submitting via Bugzilla. You'll even find a few examples to get you started. Right now, we're making the best use of existing resources, what we can use *now*: Bugzilla, cvs, Cocoon, XML, and best of all, people (editors, other authors, reviewers, committers) who care. Trust me, you'll find it quick and easy, once you take a few minutes to learn how. Why wait for Wiki when we can start writing now? I know many are excited about the prospect of using technologies like Wiki, topic maps, CMS, etc. Well, *none* of it will make a big difference without content. As a hungry user myself, I can't get too much content about Cocoon. I don't care how it arrives, how it is transformed, or how it is managed. I just want words. You know what's probably going to make the biggest short term difference with Cocoon documentation? Well, it's based on a 500+ year-old technology known as the printing press. As a user, I can't wait to read Carsten and Matthew's (and other) forthcoming books. Still, *everyone* can contribute docs, and you can do it right now. Carve out a niche for yourself as an author. If it's useful to others, your work will be published the Cocoon's web site! Just as Cocoon provides endless possibilities to build cool stuff, it also affords us an unlimited amount of creative space to write about it. Why wait? Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Paginating Content
*Thanks* Stefano. Coming soon to a How-To near you...
Diana
On Thursday, June 6, 2002, at 08:51 AM, Stefano Mazzocchi wrote:
Konstantin Piroumian wrote:
Hm... Does anybody have an idea on how to paginate the content?
Ok, damn it, I don't have time to make mark this up, but since it's the
content that is useful, here's a small tutorial for the Paginator.
- 0 -
Paginator Transformer
=
classname: org.apache.cocoon.transformation.paginatation.Paginator
location: scratchpad (available in both cocoon 2.1-dev and 2.0.3-dev)
Design idea
---
The paginator is a 'FilterTransformer' on pagination steroids. It works
filtering SAX events things out and counting page.
The design isn't very efficient since it has to process the entire file
to extract a single page. It works nicely with few tens of pages, but I
would seriously suggest *against* using it for books or very big
documents.
The good news is that its cacheable, so if the document doesn't change
and the same page is requested, there is no need to reprocess the
document.
Anyway, for static generation, all this doesn't really matter.
A simple example of use
---
Suppose you have an XML file like this
a
b/
b/
b/
b/
b/
b/
b/
/a
and you want to paginate this having 3 b elements per page. In order
to achieve this, you write a simple pagesheet (which contains the
instructions for the filter, much like a stylesheet gives instructions
to an xslt processor) like this:
?xml version=1.0?
pagesheet xmlns=http://apache.org/cocoon/paginate/1.0;
rules
count type=element name=b num=3/
/rules
/pagesheet
then you connect the two with a sitemap snippet like this:
map:match pattern=page(*)
map:generate src=document.xml/
map:transform type=paginate src=pagesheets/images.xml
map:parameter name=page value={2}/
/map:transform
map:serialize type=xml/
/map:match
and accessing the URI page(1) yields
a
b
b
b
page:page xmlns:page=http://apache.org/cocoon/paginate/1.0;
current=1
total=3
current-uri=page(1)
clean-uri=page
/
/a
which can be easily transformed into something more meaningful.
Note that the transformer processes all the pages to obtain the 'total'.
There is no way around this.
Adding navigation
-
The problem with XSLT-based pagination is that the logic is very complex
to define in XSLT and is rarely reusable across different pagination
needs. This was the main reason for the creation of a custom components
for this.
But since we have a full blown pagesheet language, there are a few other
things that we can make the Paginator do, most important, navigation.
For example, with this other pagesheet
?xml version=1.0?
pagesheet xmlns=http://apache.org/cocoon/paginate/1.0;
rules
count type=element name=b num=3/
link type=unit num=1/
/rules
/pagesheet
indicates that the transformer must understand how the page was encoded
in the given URI and provide a link to the pages +/- 1 position, if they
are available.
So, using the same environment as before we get
a
b
b
b
page:page xmlns:page=http://apache.org/cocoon/paginate/1.0;
current=1
total=3
current-uri=page(1)
clean-uri=page
page:link page=2 type=next uri=page(2)/
/page:page
/a
which indicates
1) there is no page 0, so no link is created.
2) the link goes to page 2, the type is 'next' (useful for
visualization) and the URI is page(2) (useful for linking without
XSLT-specific logic).
NOTE: the URI is re-encoded using the same pattern, this paginator
assumes that the 'round brakets' are used to identify page numbering.
Now, without changing anything, requesting page(2) would yield
a
b
b
b
page:page xmlns:page=http://apache.org/cocoon/paginate/1.0;
current=2
total=3
current-uri=page(2)
clean-uri=page
page:link page=1 type=prev uri=page(1)/
page:link page=3 type=next uri=page(3)/
/page:page
/a
while page(3) would yield:
a
b
page:page xmlns:page=http://apache.org/cocoon/paginate/1.0;
current=3
total=3
current-uri=page(3)
clean-uri=page
page:link page=2 type=prev uri=page(2)/
/page:page
/a
NOTE: here there is only one b because the original document doesn't
contain enough elements to fill the page entirely. It's the modulo of
the division.
A real-life example
---
Here are a few pagesheets which are a little more complex:
Paginating the results from DirectoryGenerator:
?xml version=1.0?
pagesheet xmlns=http://apache.org/cocoon/paginate/1.0;
rules
count type=element name=file
namespace=http://apache.org/cocoon/directory/2.0; num=16/
link type=unit num=2/
link type=range value=5/
/rules
/pagesheet
This says:
1) paginate 16 files per page
2)
Re: Wiki documentation system
On Thursday, June 6, 2002, at 03:53 PM, Jeremy Quinn wrote: This gives me wild thoughts, we could make an editor, included in the standard build, which provides a locally served form-based interface which allows cocoon users to submit documentation/doc- updates/doc-patches/recipes etc. to DocZilla as XML, via email ;) ie. if you have a working cocoon server, you can submit docs to the Cocoon project. I agree. I think the dynamic capabilities inherent in Cocoon's distribution are underutilized. I'd also like to use it for more dynamic How-Tos, something that would extend existing examples. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [docs]: Who we are
On Wednesday, June 5, 2002, at 07:35 AM, Carsten Ziegeler wrote: Hi Team, I propose that we split up the rather long list of committers in the hall of fame document into active committers and Emeritus Committers like many other projects (e.g. Axis or Struts) do. In addition we could add a short bio/note from each committer as well or at least a link to a page containing this. What do you think? I think it's an excellent idea. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [docs]: Who we are
On Wednesday, June 5, 2002, at 08:44 AM, Carsten Ziegeler wrote: Though, if having so many formats is not contradictory to the Forrest vision then I am +1 for it. We could do a simple document consisting of a table, of course. Having a specific DTD however ensures we have a common information structure across all XML Apache sub-projects, which is part of the Forrest vision. I think we should simply use the usual dtd. It available, can be used immediatly and offers all possibilites we need. +1 Let's keep our eyes on the prize -- CONTENT. Steven, the problem being: all new dtds are supposed to work with document-v11. Doesn't that unnecessarily delay these kinds of documentation efforts? As you know, I'm struggling with similar issues with other dtds. I don't want to do *anything* to delay Forrest adoption, but we also need docs... Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [docs]: Who we are
On Wednesday, June 5, 2002, at 09:17 AM, Steven Noels wrote: I upgraded the entire xml.apache.org *main* site yesterday evening to the new doc-v11.dtd and put it inside Forrest as a test case. And I am incredibly grateful for this effort. These documents were *ugly*, while Cocoon's xdocs seem structurally pretty well shaped up to me (to easily automate this transformation process). So I assume migrating to doc-v11 will not be too much of a problem for the Cocoon project. I don't think so either. Still, Carsten has time and the interest to write this doc now. If transformation will indeed be quite automated, we can update his work later. Clearly I'm saying this, fully realizing this approach may shift additional work on my shoulders when we transform *all* docs. Still, my priority is content. The only outstanding issues I have with doc-v11 is hyperlinks, the title element/attribute discussion and some personal feelings about the poor table markup. Both are currently under discussion within the Forrest group, one has been raised as a vote, so we'll get somewhere sooner than later. I posted a vote on this subject some weeks ago (http://marc.theaimsgroup.com/?t=10215429973r=1w=2), and was pretty much amazed with the amount of responses I received :-( Understanding the implications of an issue aren't always evident when you're not dealing directly with the matter. I think everyone was trusting your judgment, which I continue to do. Aren't we a bit too conservative on transitioning Cocoon to Forrest? I'm ready to start, but in a partial way. FAQs and How-Tos, as recently proposed on Forrest. I'm not ready *yet* to deal with all docs, like the one Carsten is proposing. I'll start testing this approach, as you are doing. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [doc] name for new content type?
On Tuesday, June 4, 2002, at 05:37 AM, Stefano Mazzocchi wrote: I'm approaching this very granularly. For new stuff, consider writing at least a few FAQS (it will save you time on Cocoon users). Also, consider writing a few snippets. If you have time, write a How-To. With this basic information, others can come along and extend your work: write more FAQs, snippets, and how-tos, even more complicated How-Tos (which link to less complicated How-Tos). Later, those with the big picture can combine some of this material into a Tutorial or Guide. Providing small granular ways to contribute should help users participate. Sounds great. What about recipes? Oops. I didn't *intend* to leave it out... it's just so new, not permanently fixed in my mental model yet. Don't worry. I love it. I also neglected to mention dynamic examples found in distribution. I'd also like to develop dynamic how-tos and tutorials, learning tools with hooks to webapp functionality (only in distro). My idea is that a dynamic howtos/tutorials would use resources like slash-edit to check the work of people walking through a learning process. Resulting files could be written to directories, governed by sub sitemaps e.g., where learners could incrementally build up the desired result of their howto/tutorial. It wouldn't work for all topics, but it might prove useful for others. Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [report] xml-site update
On Monday, June 3, 2002, at 05:23 AM, Stefano Mazzocchi wrote: Vadim Gritsenko wrote: Ahhh... So it appears that you have account privileges on xml.apache.org. Every committer has. Otherwise, you won't be able to commit your changes (AFAIU this system). Nop. CVS and HTTPD reside on different machines with different account priviledges. Diana, I'll have [EMAIL PROTECTED] give you account priviledges on http://xml.apache.org so that you can update the site yourself directly. Deal? Deal. Thanks. I'll need a few tips ... :) Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
