cziegeler 02/01/17 08:17:52
Modified: src/documentation/xdocs index.xml
Log:
Corrected typos
Revision Changes Path
1.3 +9 -9 xml-cocoon2/src/documentation/xdocs/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/index.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- index.xml 17 Jan 2002 06:33:26 -0000 1.2
+++ index.xml 17 Jan 2002 16:17:52 -0000 1.3
@@ -37,7 +37,7 @@
<p>
This documentation is not complete because documentation is never complete
anyway. However the current
- release is stable and tested thoroughly and you'll find lots of samples which
shows and explains
+ release is stable and tested thoroughly and you'll find lots of samples which
show and explain
the power of Apache Cocoon @version@. We welcome you into this new world of XML
wonders :-)
</p>
<p>
@@ -93,7 +93,7 @@
concept" stage, it is now considered a main design constraint for Cocoon
scalability.</p>
- <p>Since the goal of Cocoon 2 is the ability to process
+ <p>Since the goal of Cocoon is the ability to process
simultaneously multiple 100Mb documents in JVM with a few Mbs of heap size,
careful memory use and tuning of internal components is a key issue. To reach
this goal, an improved API model was needed. This is now identified in the SAX
@@ -287,12 +287,12 @@
interpretation solutions like DCP that will be removed.</p>
<note>Some of these features are already present in latest Cocoon 1.x
- releases but the Cocoon 2 architecture will make them central to its new
+ releases but the Cocoon architecture will make them central to its new
core.</note>
</s1>
<s1 title="Sitemap">
- <p>In Cocoon 2 terminology, a <em>sitemap</em> is the collection of pipeline
+ <p>In Cocoon terminology, a <em>sitemap</em> is the collection of pipeline
matching informations that allow the Cocoon engine to associate the requested
URI to the proper response-producing pipeline.</p>
@@ -309,23 +309,23 @@
design changes since it's very flexible and was not polluted by early design
constraints since it appeared in later versions. The issue regarding static
file caching that, no matter what, will always be slower than direct web server
- caching, means that Cocoon 2 will be as <em>proxy friendly</em> as possible.</p>
+ caching, means that Cocoon will be as <em>proxy friendly</em> as possible.</p>
<p>To be able to put most of the static part of the job back on the web
- server (where it belongs), Cocoon 2 will greatly improve its command line
+ server (where it belongs), Cocoon will greatly improve its command line
operation, allowing the creation of <em>site makefiles</em> that will
automatically scan the web site and the source documents and will provide a
way to <em>regenerate</em> the static part of a web site (images and tables
included!) based on the same XML model used in the dynamic operation version.</p>
- <p>Cocoon 2 will, in fact, be the integration between Cocoon 1 and Stylebook.</p>
+ <p>Cocoon will, in fact, be the integration between Cocoon 1 and Stylebook.</p>
<p>It will be up to the web server administrator to use static
regeneration capabilities on a time basis, manually or triggered by some
- particular event (e.g. database update signal) since Cocoon 2 will only provide
+ particular event (e.g. database update signal) since Cocoon will only provide
servlet and command line capabilities. The nice integration is based on the
fact that there will be no behavioral difference if the files are dynamically
- generated in Cocoon 2 via the servlet operation and cached internally or
+ generated in Cocoon via the servlet operation and cached internally or
pre-generated and served directly by the web server, as long as URI contracts
are kept the same by the system administrator (via URL-rewriting or aliasing)</p>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
