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 @[EMAIL PROTECTED] 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]
