Livedocs is a tool to display Doc Book? XML documents to a web browser on the fly without the need of building all HTML target files first. It was started as a project to simplify the task of PHP Manual contributors, to check their changes as they will show up in the documentation. To use Livedocs, a little preprocessing work is needed, but after that, the script collection works instantly on modified XML files.
The main advantage of Livedocs for the PHP Manual is the dramatically reduced time-to-live interval, since modified XML documents can be pushed to servers without the need of building all the HTML files even for small changes. A list of currently planned Livedocs advantages and features include:
* Decrease the time between doc commit and use by documentation users.
* Decrease the time between finding a doc bug, and having it fixed.
* Provide useful search results for keywords found in the manual.
* Keep track of relationships between translated files to their English equivalents by notifying readers if they are reading a seriously outdated translation.
* Either generate all changed documents at set time intervals or do it live by checking the status on each request. Or a mix of both.
* Enhance the users experience while perusing the manual.
Also, documentation authors may visualize their doc changes *instantly* thus attracting content editors and translators to the project. One of the main hurdles is developers lacking the tools or patience to build the manual in order to view their changes. Livedocs however removes this overwhelming development environment requirement.
And being open source, Livedocs is freely available for similar minded projects to benefit from. The main target audience is large projects however due to the proposed feature set most any project will benefit.
The current status of Livedocs:
* Livedocs exists and has a nice solid base: 
http://cvs.php.net/viewcvs.cgi/livedocs/
* A core of developers express interest in Livedocs and want to help it along further
* An existing bug database (category) at: http://tinyurl.com/ldp4b
This project exists currently but is not active nor is it implemented. Currently it can generate the PHP manual from Doc Book? markup but is only in the beta stages. The documentation team feels that in order for Livedocs to fully reach its potential, and to be used for all PHP projects (and beyond), it must be improved and brought to a releasable state.
Primary goals and requirements for this project are:
* Work well with all translations/languages
* Replace the pregenerated php.net manuals entirely
* Work for other PHP projects, such as PEAR, Smarty, PHP-GTK
* Solve the OOP documentation problem
* Make entity changes not require execution of build.sh
* Allow usable image integration into the manual
* See also the TODO and BUGS files
* Keep PHP 4 compatibility
* Use sqlite for the entities and other metadata
* Document how to implement Livedocs for a Doc Book? project
* Document how to implement a given feature, such as making the <acronym> tag work
* Document how to use Livedocs
Secondary goals:
* Improved search capability for local copies (would replace CHM version of the manual)
* On-the-fly user customizability of manual results (CSS, Version specific, printable, ...)
* Put predefined constants on their own page (currently listed within reference.xml)
* Consider note tags for user submitted notes/comments (although this isn't specific to Livedocs)
* Work for other Doc Book? based projects (generic)
Longer term goals/ideas/considerations:
* Online WYSIWYG editing of manual pages, which includes: edit, submit, xmlint, approve, make test, commit. This would greatly increase translation updates.
* Consider an authorized/approval type wiki style of editing.
* Bug submission integration with the manual itself also allowing translations their own bug system. Could be integrated with the proposed user note tags.
* Consider integration with phpDocumentor
During the summer all primary goals are to be completed with planning for secondary and longer term goals along the way. Most likely secondary goals will also be met, and hopefully the longer term goals too.
Planning (2 weeks):
Through collaboration with the PHP Team, and those familiar with Livedocs, narrow down a roadmap for this project. This will include items doable for the summer and items tagged for beyond that time. Definite (and doable) goals will be created for Livedocs future. With a basic plan already set in place, this stage can be seen more as a brain storming session but will also provide a template to monitor progress.
Learning (2 weeks):
With a plan set, technologies will need further research. This may include xslt, xsltproc, sqlite, Livedocs itself, PHP, and whatever else comes up during the planning stages. The main purpose here is that in order to develop efficiently, I'll need to know exactly how all this applies to Livedocs, and how versions of said tools will affect the results.
Development (forever):
The heart of the summer. This is where the plan comes to life, where Livedocs changes actually happen. Ideas are one thing but implementation is another. All code will go through cvs.php.net and be monitored by my peers and mentor(s).
I, Philip Olson, have extensive experience documenting the PHP manual and am very much familiar with the issues/limitations surrounding the current DSSSL/XSLT system, namely, the frustrations it sometimes causes us. Also, I fully understand how fellow members of the Documentation team are eager to get Livedocs going and look forward to making it happen.