Re: simplified docbook plugin
Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: David Crossley wrote: Are you just talking about the stylesheet or the DTDs too? The trouble with the DTDs is that they will make this plugin, and our SVN trunk, very cumbersome. How many versions of Full DocBook and Simplified DocBook will we support? ... The issue is more about efficiency. When the xml parser encounters a document type declaration in an xml instance, then it must resolve the DTD and everything that is thereby referenced. So if you don't provide local copies, then there are network trips on every parse. We could not provide them, and just give people documentation about how to configure their own. In fact we already have that. The trouble is that they don't. Then poor Forrest would appear awfully slow to them. How about we enhance the plugin install mechanism to offer to download an additional package of DTD's. So the install process would be: - set forrest.properties - forrest - approve plugin licenses (to be done) - specify required DTD's - install selected DTD's This way we can tell users, these DTD's are xMb, are you sure you want to install them? If you don't install them then Forrest will only work whilst you are online and will not perform as fast This is exactly the point that we arrived the last time that we discussed this topic. So i presume that we need to develop a DTD package descriptor. Some issues ... * Sometimes DTDs are in a compressed archive, complete with an XML Catalog which defines each resource and maps it to a local relative URI. * Sometimes there is a single DTD file. * Sometimes a DTD refers to other pieces via local references. * Sometimes there is no XML Catalog provided, so we will need a default one. * How would Forrest automatically know that the DTDs are needed? Perhaps we can have an Ant thing to scan their project source tree and match document type declarations with the installed XML Catalogs. It is not my immediate itch to take on this job, but i will certainly help where i can. There is also a need for a similar download mechanism for sets of XSL stylesheets. For example, the Apache XML Commons website uses Forrest. For the Resolver documentation, Forrest uses the Forrest-supplied DocBook DTDs and the project sitemap has a hard-coded URL to the local system-supplied Full DocBook XSLs. David
[jira] Created: (FOR-602) The 'build test' fails because does not load project XML Catalog
The 'build test' fails because does not load project XML Catalog Key: FOR-602 URL: http://issues.apache.org/jira/browse/FOR-602 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley The 'build test' cannot find the CatalogManager.properties and so it does not load the project XML Catalog. Then the parser fails to find some declared entities. All is okay when doing a 'forrest seed; forrest'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Simple committership
On Fri, 2005-07-29 at 15:30 +0200, Nicola Ken Barozzi wrote: snip valuable background information/ If we want to include simple committership as a role, I would like to hear someone explain how simple committership will solve more issues than it may cause, especially given the above. In particular, I would like to have some real-life examples that show how simple committership would have been useful. Like David and Nicola stated the Forrest project normally votes all committer directly into the PMC as well. I personally see special occasions (besides GSoC) where I would like to see a simple committership or like I would call it PMC incubation. It should follow the basic idea of the Apache Incubator [1] which is for new projects at Apache. A large part of the Incubator's effort will be devoted to providing documentation on how the Foundation works, and how to get things done within its framework. As a consequence, it is expected that the Incubator will also become a reference for new contributors to any of the Apache projects. My reasoning is that we can ensure that this newbies can learn the apache way to it fullest (which is one of the most important point in the process to become a PMC member) without the pressure to be an official PMC member. New committers have to learn a) how the Foundation works b) how the Project works One can argue that this should be learned before becoming a committer on the mls but I see a certain process behind it which takes time (some times too much). Now it was asked for a real-life example. That could be myself. ;-) I have been a Wyona CMS committer before it became an official Apache Incubator project. The company Wyona donated then the code base to the ASF as cocoon subproject in incubation called Apache Lenya. I had general experience in how a open source project and community is working but that have been quite different from the ASF way that I had to learn. Within the one year where Apache Lenya has been in the incubator I learned the basics (IMO learning) on how the Foundation works (a) (never stops). As Apache Lenya committer we were given not only committing rights to lenya but as well to cocoon, forrest and xml. I started to use them here on forrest when getting into the documentation for lenya. In lenya we are using forrest to create our documentation and website. We had a custom skin and heaps problems with maintaining it because forrest is developing very rapid. The lenya skin was nearly all div based. At the time I started here in forrest there was an issue about an all div based skin. The result is called pelt. While I was developing the skin I had simple committership to forrest. I am happy that I could concentrate on developing the skin and meanwhile learning all the new responsibilities of a PMC member. After a while I was invited to join the PMC and helping on the long run of forrest. I could fully participate in the project as committer. I just did not had a counting vote but normally forrest consider every concern. One thing that helped me is that the PMC normally watch the committs of new committer more careful to ensure that e.g. all legal issues are meet. PMC membersnot only have to help new committers to learn the duty of a PMC member in the specific project (b) but also like the incubator teach the values of an ASF project and its duties (a). There have been a thread on all PMC lists about the duties (around 10 points) of a PMC member by Davanum Srinivas. I was given committership to apply my own patches for cocoon, forrest and xml. That leveraged this project (faster process) because other PMC members do not had to do that. Then especially David taught me as well the PMC duties and I became a PMC member. The important point is that new committer are generally overwhelmed by the information and infrastructure of the project and the ASF. Some learn better step by step understanding what is ASF all about and what a PMC member have to do (I consider myself as such a somebody). I was lucky and made my experience in the incubator *and* here but the committers we vote in normally do not have this incubator experience which I consider most valuable. In essence, Jakarta became a small Apache, creating sub-roles where the PMC members were like Apache members, and committers were like PMC members. In Jakarta it's usual that committers vote, but in fact their vote is not legally valid, and they *cannot* release code without a PMC vote. This also created a big disconnect between the Board of Directors and Jakarta, and most projects were having little or no oversight, and the number of Jakarta committers that was an Apache member was extremely low. The point you are maybe up to is that we can create a closed group that new committer are not able to enter. We limit the PMC membership to a certain group of people for whatever particular reason. The downside is that committers cannot be responsible for the
Re: [jira] Created: (FOR-601) Last modified time of Goggle Sitemap incorrect
Errr... I'm not sure what you mean. The date is currently inserted by:I was just introducing the map:generator issue... In my opinion we should not be adding a last-modified time until we can add a proper one. This element is optional in the google sitemap and I am sure that Google would appreciate no information over and above false information.I only use it because I don't use Forrest in a dynamic environment, but all my pages are created dynamically at build time. Do you think a map:generator could be responsible for adding this or making the info available to the the http header if it has access to the necessary objects. There are a number of options: - create a special generator that adds the last-modified time to meta-data based on src file timestamp (as you appear to be suggesting) - how would this then make it into the google sitemap? IMHO, this is the best option. The LinkStatusGenerator can then read it from the http header and added it to its xml output. - extend the link status generator so that it adds the last modified time of the src file to its output This will need to be done, but again IMHO only to add http headers from the crawled URLs to the xml output. -- Regards,Ruswww.discountdracula.com Your Bargain BloodSucka:Suckin' the Best Deals Outta the Web
[jira] Updated: (FOR-603) How to become a Forrest Committer
[ http://issues.apache.org/jira/browse/FOR-603?page=all ] Addison Berry updated FOR-603: -- Attachment: committer.xml com.aart I basically just started a doc by cutting and pasting Ross and David's discussion on the list. I've attached the xml doc and an ascii art file. How to become a Forrest Committer - Key: FOR-603 URL: http://issues.apache.org/jira/browse/FOR-603 Project: Forrest Type: Improvement Components: Documentation and website Reporter: Addison Berry Priority: Minor Attachments: com.aart, committer.xml Issue brought up on the mail list at http://marc.theaimsgroup.com/?l=forrest-devamp;m=112239074108858amp;w=2 re: creating documentation on becoming a committer in Forrest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-603) How to become a Forrest Committer
How to become a Forrest Committer - Key: FOR-603 URL: http://issues.apache.org/jira/browse/FOR-603 Project: Forrest Type: Improvement Components: Documentation and website Reporter: Addison Berry Priority: Minor Attachments: com.aart, committer.xml Issue brought up on the mail list at http://marc.theaimsgroup.com/?l=forrest-devamp;m=112239074108858amp;w=2 re: creating documentation on becoming a committer in Forrest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FOR-603) How to become a Forrest Committer
[ http://issues.apache.org/jira/browse/FOR-603?page=all ] David Crossley closed FOR-603: -- Fix Version: 0.8-dev Resolution: Fixed Wow, Addi, you are a champ. This is one of the most important documents that we could have on our website. Thanks for doing such a nice job of converting that mail list discussion. We need more of that type of effort. I left this issue open for a while because there sure to be more changes. There is another discussion happening on a related topic. Anyway I added your patch as-is, except that i converted tabs to two-space. I also folded long lines into about 80-characters wide. The reason for this is very important. I am now going to proceed to make some minor changes and you will see via the commit diffs (see www.mail-archive.com if you are not subscribed). If each paragraph was one enourmous long line, then it would be difficult to know the changes. (Yes i am adding stuff like that to a new how to be a developer document.) I have left this issue open for a while because there are sure to be more changes. The discussions are not finished. How to become a Forrest Committer - Key: FOR-603 URL: http://issues.apache.org/jira/browse/FOR-603 Project: Forrest Type: Improvement Components: Documentation and website Reporter: Addison Berry Assignee: David Crossley Priority: Minor Fix For: 0.8-dev Attachments: com.aart, committer.xml Issue brought up on the mail list at http://marc.theaimsgroup.com/?l=forrest-devamp;m=112239074108858amp;w=2 re: creating documentation on becoming a committer in Forrest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (FOR-603) How to become a Forrest Committer
[ http://issues.apache.org/jira/browse/FOR-603?page=all ] David Crossley reopened FOR-603: How to become a Forrest Committer - Key: FOR-603 URL: http://issues.apache.org/jira/browse/FOR-603 Project: Forrest Type: Improvement Components: Documentation and website Reporter: Addison Berry Assignee: David Crossley Priority: Minor Fix For: 0.8-dev Attachments: com.aart, committer.xml Issue brought up on the mail list at http://marc.theaimsgroup.com/?l=forrest-devamp;m=112239074108858amp;w=2 re: creating documentation on becoming a committer in Forrest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (FOR-603) How to become a Forrest Committer
[ http://issues.apache.org/jira/browse/FOR-603?page=all ] David Crossley reassigned FOR-603: -- Assign To: (was: David Crossley) How to become a Forrest Committer - Key: FOR-603 URL: http://issues.apache.org/jira/browse/FOR-603 Project: Forrest Type: Improvement Components: Documentation and website Reporter: Addison Berry Priority: Minor Fix For: 0.8-dev Attachments: com.aart, committer.xml Issue brought up on the mail list at http://marc.theaimsgroup.com/?l=forrest-devamp;m=112239074108858amp;w=2 re: creating documentation on becoming a committer in Forrest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-604) The document-v* warning element does not get rendered properly
[ http://issues.apache.org/jira/browse/FOR-604?page=all ] David Crossley updated FOR-604: --- Attachment: 604-screenshot.png The document-v* warning element does not get rendered properly -- Key: FOR-604 URL: http://issues.apache.org/jira/browse/FOR-604 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley Fix For: 0.8-dev Attachments: 604-screenshot.png The warning element is rendered differently to the note element. Perhaps it only happens with the pelt skin - not yet verified. See screenshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-604) The document-v* warning element does not get rendered properly
The document-v* warning element does not get rendered properly -- Key: FOR-604 URL: http://issues.apache.org/jira/browse/FOR-604 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley Fix For: 0.8-dev Attachments: 604-screenshot.png The warning element is rendered differently to the note element. Perhaps it only happens with the pelt skin - not yet verified. See screenshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-604) The document-v* warning element does not get rendered properly
[ http://issues.apache.org/jira/browse/FOR-604?page=comments#action_12317891 ] David Crossley commented on FOR-604: Thanks for the research. I reckon it is not by deliberate design, rather a matter of inconsistent evolution. Glancing at the history http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/skins/pelt/css/basic.css it seems that we had a warning and fixme defined in a certain way, and frame used for notes in another way. Yes please Gav, those box types should all be consistent, so please tweak the CSS to make them all look good like Note does. The document-v* warning element does not get rendered properly -- Key: FOR-604 URL: http://issues.apache.org/jira/browse/FOR-604 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley Fix For: 0.8-dev Attachments: 604-screenshot.png The warning element is rendered differently to the note element. Perhaps it only happens with the pelt skin - not yet verified. See screenshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Fwd: RefDoc - Neutral XML Document Format Input/Current State]
Cyriaque Dupoirieux wrote: Diwaker Gupta a ?crit : This sounds exciting. Do we have access to any example/samplout output of RefDoc? One of the interesting possibilities is to generate examples automagically. For instance by correlating the Java source file for a Cocoon Generator with its usage in a processing pipeline. w.r.t Forrest, it would be nice to have a way of generating more friendly documentation of the DTDs. The current DTD documentation is good, but I think it could get better. Please see the DTDx plugin todo notes [1] and issue FOR-221 [2]. [1] http://forrest.apache.org/pluginDocs/plugins_0_70/org.apache.forrest.plugin.input.dtdx/todo.html [2] http://issues.apache.org/jira/browse/FOR-221 NekoDTD generated dtd documentation needs improvement, some bugs. The NekoDTD parser author would be pleased to receive patches. I agree that other representations of the DTDs could also help. Right now its a very mechanical kind of documentation -- just listing the attributes and children and parents and so on. A little more annotated DTD documentation would be great (what does each element mean, what are recommended usages and so on). Excellent idea, I remember - when I was young - that I spent lot of time to understand how I could have the former link and fork behaviour whereas we only have a tag in document-v20. Maybe a little comment of the author used to be displayed in the generated documentation should have helped me... However the documented examples would have helped. [3] http://forrest.apache.org/dtdx/document-v20.html#changes Anyway, it will be very good if the RefDoc work can help with enhanced DTD documentation. How far can we go there? I mean, if the contents of [3] were all embedded in the actual DTDs, then the DTDs would become rather bloated. Perhaps have some minor explanations, but still use specific example documents for the full story. David
[jira] Updated: (FOR-221) NekoDTD generated dtd documentation needs improvement, some bugs
[ http://issues.apache.org/jira/browse/FOR-221?page=all ] David Crossley updated FOR-221: --- Comment: was deleted NekoDTD generated dtd documentation needs improvement, some bugs Key: FOR-221 URL: http://issues.apache.org/jira/browse/FOR-221 Project: Forrest Type: Improvement Components: Core operations Versions: 0.8-dev Reporter: David Crossley DTD Documentation http://forrest.apache.org/docs/dtd-docs.html Paraphrased from a discussion with Andy, i.e. his suggestions for some improvements. Bugs ... *) element declarations list in the table of contents are empty *) list of elements is alphabetic but the elements are not Enhancements ... *) sort the list of elements appearing in content model choice groups *) show parameter entity references in content models. Then, using JavaScript, the user could expand or collapse the content of the parameter entity. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
