Return-Path: Delivered-To: apmail-forrest-svn-archive@www.apache.org Received: (qmail 49010 invoked from network); 19 Dec 2005 01:34:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Dec 2005 01:34:07 -0000 Received: (qmail 91443 invoked by uid 500); 19 Dec 2005 01:34:07 -0000 Delivered-To: apmail-forrest-svn-archive@forrest.apache.org Received: (qmail 91393 invoked by uid 500); 19 Dec 2005 01:34:06 -0000 Mailing-List: contact svn-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Forrest Developers List" List-Id: Delivered-To: mailing list svn@forrest.apache.org Received: (qmail 91375 invoked by uid 99); 19 Dec 2005 01:34:06 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Dec 2005 17:34:06 -0800 X-ASF-Spam-Status: No, hits=-9.4 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 18 Dec 2005 17:33:56 -0800 Received: (qmail 48774 invoked by uid 65534); 19 Dec 2005 01:33:35 -0000 Message-ID: <20051219013335.48773.qmail@minotaur.apache.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r357603 [2/11] - in /forrest/site: ./ docs_0_60/ docs_0_60/howto/ docs_0_60/howto/bugzilla-patch/ docs_0_70/ docs_0_70/howto/ docs_0_70/howto/cvs-ssh/ docs_0_80/ docs_0_80/howto/ docs_0_80/howto/cvs-ssh/ dtdx/ pluginDocs/plugins_0_70/ plugi... Date: Mon, 19 Dec 2005 01:33:15 -0000 To: svn@forrest.apache.org From: crossley@apache.org X-Mailer: svnmailer-1.0.5 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Modified: forrest/site/docs_0_60/howto/howto-pdf-tab.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_60/howto/howto-pdf-tab.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_60/howto/howto-pdf-tab.html (original) +++ forrest/site/docs_0_60/howto/howto-pdf-tab.html Sun Dec 18 17:31:25 2005 @@ -351,16 +351,16 @@
Steps

The procedure outlined below will define a project - sitemap.xmap and create a new - pdf-tab.xmap based on the aggregate.xmap + sitemap.xmap and create a new + pdf-tab.xmap based on the aggregate.xmap
Create your project's main sitemap.xmap

Simply copy the sitemap.xmap from the Forrest sitemaps at - ${FORREST_HOME}/context/sitemap.xmap into your - src/documentation directory (or wherever + ${FORREST_HOME}/context/sitemap.xmap into your + src/documentation directory (or wherever ${project.sitemap-dir} points to).
@@ -378,7 +378,7 @@
- Edit the project sitemap.xmap to comment-out the match + Edit the project sitemap.xmap to comment-out the match for the sitemap like this:
@@ -396,7 +396,7 @@
 Edit project sitemap.xmap to mount pdf-tab.xmap
 
       Insert the following lines after the
-      <map:match pattern="site.xml">
+      <map:match pattern="site.xml">
       pipeline in the section called "SOURCE FORMATS".
     
 @@ -409,7 +409,7 @@
 
 Edit the file pdf-tab.xmap
 
-      The <map:match pattern="*.xml"> element
+      The <map:match pattern="*.xml"> element
       should look like the following:
     
 @@ -433,7 +433,7 @@
 
 Edit your site.xml
 Add the following entry to your site.xml in the
-      <about> element
+      <about> element
     
 ... 
 <whole_foosite href="pdf-tab.html" label="sub site" />
@@ -453,11 +453,11 @@
     
 
       This allows you to link to it via a
-      <link href="site:v0.60//whole_foosite">
+      <link href="site:v0.60//whole_foosite">
       reference. 
     
 Add to every element that should be included in the pdf-tab.pdf
-      the attribute wholesite="true"
+      the attribute wholesite="true"
 
  <sample-wiki label="Wiki page" href="wiki-sample.html"
@@ -467,8 +467,8 @@
 Note
 This attribute will be inherited by all children of the element. 
 	 Do not use it in the parent element that contains the 
-	 <whole_foosite href="pdf-tab.html" label="pdf-tab" /> 
-	 as the child (will cause a stack overflow if you do)!!!
+	 <whole_foosite href="pdf-tab.html" label="pdf-tab" /> 
+	 as the child (will cause a stack overflow if you do)!!!
 	
 
 
@@ -477,9 +477,9 @@
       Line 4 of our example
       

       
-<map:parameter name="include" value="//*[@wholesite='true']"/>
+<map:parameter name="include" value="//*[@wholesite='true']"/>
       looks at your site.xml and will match every element containing the
-      wholesite="true" attribute. For example, to use the "samples"
+      wholesite="true" attribute. For example, to use the "samples"
       tab ...
     
 @@ -491,8 +491,8 @@
     
 
       It matches all of the elements that contain
-      wholesite="true"
-      (in our example <samples>
+      wholesite="true"
+      (in our example <samples>
       and its "children") for the content of the pdf file to be generated.
     
  
@@ -507,33 +507,33 @@
     
 
       This example shows that you can as well exclude site(s) from the aggregation 
-      by using the wholesite="false" attribute. This attribute will be as well inherited 
+      by using the wholesite="false" attribute. This attribute will be as well inherited 
       by all children of the element.
     
 
       Line 8 defines the title of the pdf file by taking the content
       of the project-name variable in
-      skinconf.xml and adding some funny text:
+      skinconf.xml and adding some funny text:
       

       
-<map:parameter name="title" value="{conf:project-name}: Still My Foo Site"/>
+<map:parameter name="title" value="{conf:project-name}: Still My Foo Site"/>
     
 
 
 Note
 
-      In the original aggregate.xmap there is the line
+      In the original aggregate.xmap there is the line
       

       
-<map:parameter name="ignore" value="{1}"/>
+<map:parameter name="ignore" value="{1}"/>
       
 

       just before the title definition
-      (<map:parameter name="title" value=".../>).
+      (<map:parameter name="title" value=".../>).
       Be sure to delete it or comment it out if you like to generate a
       pdf-file for specific sites. You only need it for the generation of
       one pdf-file for the whole project (this is what
-      aggregate.xmap usually does).
+      aggregate.xmap usually does).
     
 
 

Modified: forrest/site/docs_0_60/linking.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_60/linking.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_60/linking.html (original)
+++ forrest/site/docs_0_60/linking.html Sun Dec 18 17:31:25 2005
@@ -348,7 +348,7 @@
 
 
         This document describes Forrest's internal URI space; how it is managed
-        with the "site.xml" configuration file, how menus are generated,
+        with the "site.xml" configuration file, how menus are generated,
         and how various link schemes (site: and ext:) operate.
         An overview of the implementation is also provided.
       
@@ -359,9 +359,9 @@
 site.xml
 
 
-        The "site.xml" configuration file is what we would call a "site map"
+        The "site.xml" configuration file is what we would call a "site map"
         if Cocoon hadn't already claimed that term. 
-        The "site.xml" is a loosely structured XML file, acting as a map of the
+        The "site.xml" is a loosely structured XML file, acting as a map of the
         site's contents.  It provides a unique identifier (an XPath address)
         for "nodes" of information in the website.  A "node" of site information
         can be:
@@ -374,17 +374,17 @@
 
A specific page, e.g. "the FAQ page"
         
 A specific section in a page, e.g. the "general" section of the FAQ
-          page (identified by id="general" attribute)
+          page (identified by id="general" attribute)
       
 
 
-        In addition to providing fine-grained addressing of site info, the site.xml
+        In addition to providing fine-grained addressing of site info, the site.xml
         allows metadata to be associated with each node, using
-        attributes or child elements.  Most commonly, a label
+        attributes or child elements.  Most commonly, a label
         attribute is used to provide a text description of the node.
       
 
-        There are currently two applications of site.xml
+        There are currently two applications of site.xml
       
 
 
@@ -394,21 +394,21 @@
 
         
 
-site.xml is used to generate the menus for the HTML website.
+site.xml is used to generate the menus for the HTML website.
         
 
 Indirect linking
 
         
 
-site.xml provides a basic aliasing mechanism for linking, e.g. one
+site.xml provides a basic aliasing mechanism for linking, e.g. one
           can write <link href="site:v0.60//changes"> from anywhere in the site, and
           link to the "changes" information node (translated to changes.html).
           More on this below.
       
 
 
-        Here is a sample site.xml ... a modified version from Forrest's
+        Here is a sample site.xml ... a modified version from Forrest's
         own website:
       
 @@ -470,25 +470,25 @@
 
         
 The root element must be "site", and normal content should be in the
-          namespace http://apache.org/forrest/linkmap/1.0 (Feel
+          namespace http://apache.org/forrest/linkmap/1.0 (Feel
           free to mix in your own content (RDF, dublin core, etc) under new
           namespaces)
         
-Element names are used as identifiers.  The "foo" in
-          "site:foo" must therefore be a valid NMTOKEN.
+Element names are used as identifiers.  The "foo" in
+          "site:foo" must therefore be a valid NMTOKEN.
         
-Elements with href attributes can be used as identifiers
-          in "site:" URIs
+Elements with href attributes can be used as identifiers
+          in "site:" URIs
         
 Relative href attribute contents are "accumulated" by prepending hrefs
           from ancestor nodes
         
-Elements without label attributes (and their children)
+
Elements without label attributes (and their children)
           are not displayed in the menu.
         
-Elements below external-refs are mapped to the
-          "ext:" scheme.  So "ext:commons/resolver/" becomes
-          "http://xml.apache.org/commons/resolver/"
+Elements below external-refs are mapped to the
+          "ext:" scheme.  So "ext:commons/resolver/" becomes
+          "http://xml.apache.org/commons/resolver/"
       
 
 
@@ -498,11 +498,11 @@
 Generating Menus
 
 
-        Two files are used to define a site's tabs and menu (site.xml and
-        tabs.xml).  Both files are located in
-        src/documentation/content/xdocs/
+        Two files are used to define a site's tabs and menu (site.xml and
+        tabs.xml).  Both files are located in
+        src/documentation/content/xdocs/
 
-Assume that our tabs.xml looks like this:
+Assume that our tabs.xml looks like this:
  <tabs ...>
     <tab id="home" label="Home" dir=""/>
@@ -510,48 +510,48 @@
     <tab id="howto" label="How-Tos" dir="community/howto"/>
 </tabs>
       
-Using the "site.xml" listed above, we would get these menus:
+Using the "site.xml" listed above, we would get these menus:
 
         
    
            
         
       
-When using the "dir" attribute as above the value of the
-      "indexfile" parameter is appended to the value of the 
-      "dir" attribute (together with a preceding '/'). For example,
+
When using the "dir" attribute as above the value of the
+      "indexfile" parameter is appended to the value of the 
+      "dir" attribute (together with a preceding '/'). For example,
       the link for the community tab above is 
-      community/mailLists.html. Note that "indexfile"
-      defaults to "index.html" if no value is supplied. Therefore the
-      link for the howto tab is community/howto/index.html
+      community/mailLists.html. Note that "indexfile"
+      defaults to "index.html" if no value is supplied. Therefore the
+      link for the howto tab is community/howto/index.html
 
 
 Tabs for External Resources
 A tab can refer to an external resource by using the 
-        "href" attribute instead of the "dir" attribute.
-        The value of "href" should be the URI of the resource you wish 
+        "href" attribute instead of the "dir" attribute.
+        The value of "href" should be the URI of the resource you wish 
         to link to. For example:
  <tab id="apache" label="XML Apache" href="http://xml.apache.org/"/>
         
-Unlike the "dir" attribute, the value of "href"
+
Unlike the "dir" attribute, the value of "href"
         is left unmodified by Forrest unless it is root-relative and obviously 
         specifies a directory (ends in '/'). In which case /index.html will be 
         added.
 
 Selecting menu entries
 Forrest decides which menu entries to display, by examining the
-          "tab" attributes in the site.xml file. The children of 
-          all site.xml entries with a
-          "tab" which is equal to that of the current page, are
+          "tab" attributes in the site.xml file. The children of 
+          all site.xml entries with a
+          "tab" which is equal to that of the current page, are
           added to the menu, whilst the element itself forms the root of that
-          part of the menu (see the "community" element in the 
+          part of the menu (see the "community" element in the 
           example below). Child elements that have a different 
-          "tab" attribute value will appear in the menu for their
+          "tab" attribute value will appear in the menu for their
           parents, and will also form the root of a new menu for a tab with 
-          the appropriate name (see the "howto-samples" element
+          the appropriate name (see the "howto-samples" element
           below).
-Consider our site.xml example:
+Consider our site.xml example:
  <site label="Forrest" href="" tab="home"
   xmlns="http://apache.org/forrest/linkmap/1.0">
@@ -576,25 +576,25 @@
         <step1 label="Step 1" href="step1.html"/>
       ...
 
-          Every site.xml node can potentially have a "tab" attribute.  If
-          unspecified, nodes inherit the "tab" of their parent.  Thus
+          Every site.xml node can potentially have a "tab" attribute.  If
+          unspecified, nodes inherit the "tab" of their parent.  Thus
           everything in the <about> section has an implicit
-          tab="home" attribute.
+          tab="home" attribute.
 
 Note
 You can see this by viewing your site's 
         abs-menulinks pipeline in a
           browser.
 
-Say that the user is viewing the linking.html
+
Say that the user is viewing the linking.html
           page.  The <linking> node has an implicit tab
-          value of "home".  Forrest will select all nodes with
+          value of "home".  Forrest will select all nodes with
             tab="home" and put them in the menu.
         

 
 Alternative menu selection mechanisms.
 
-          The "tab" attribute-based scheme for selecting a menu's
+          The "tab" attribute-based scheme for selecting a menu's
           entries is not the only one, although it is the most flexible.  Here
           we describe a few alternatives.
         
@@ -613,11 +613,11 @@
           
 
             
-Edit forrest.properties and set
-              project.menu-scheme=directories
+
Edit forrest.properties and set
+              project.menu-scheme=directories
 
             
-Remove the "id" attributes from tabs.xml
+
Remove the "id" attributes from tabs.xml
               entries.
           
 
@@ -625,21 +625,21 @@
 Specifying menus with book.xml
 
             Historically, menus in Forrest have been generated from a
-            book.xml file, one per directory.  This mechanism is
-            still available, and if a book.xml is found, it will be
-            used in preference to the menu generated by the site.xml file. The book.xml
-            files can use "site:" URIs to ease the maintenance burden
+            book.xml file, one per directory.  This mechanism is
+            still available, and if a book.xml is found, it will be
+            used in preference to the menu generated by the site.xml file. The book.xml
+            files can use "site:" URIs to ease the maintenance burden
             that led to obsolescence of book.xml files.  In general, however, we
-            recommend that users avoid book.xml files.
+            recommend that users avoid book.xml files.
           
 
 Selecting the current tab
 
           The tab selection algorithm is quite simple: the tab with the
-          "id" which matches that of the current site.xml
+          "id" which matches that of the current site.xml
           node is "selected". If you experience any problems, try to add a 
-          <foo label="Foo" href="index.html"/> to the
-          site.xml configuration.
+          <foo label="Foo" href="index.html"/> to the
+          site.xml configuration.
         
 

 
@@ -651,35 +651,35 @@
       is created from the titles of each section in your xdoc. By default only
       sections up to two levels deep are included and the table of contents is
       displayed at the top of the page. However, you can configure this
-      behaviour in src/documentation/skinconf.xml using the 
-      "toc" element.
+      behaviour in src/documentation/skinconf.xml using the 
+      "toc" element.
  <toc level="2" location="page"/>
       
 
         
 
-level - is the depth to which you
+level - is the depth to which you
         want your table of contents to go. Setting it to "3" will therefore 
         include sections nested to 3 levels. Setting this to "0" will result in
         no table of contents being generated.
         
 
-location - indicates where you
+location - indicates where you
         want the table of contents to be rendered. It can be set to one of
         three values:
           
             
 
-page - the table of contents will be rendered
+page - the table of contents will be rendered
             at the top of the body of your page
             
 
-menu - the table of contents will be rendered
+menu - the table of contents will be rendered
             in the menu to the left of the body of the page
             
 
-menu, page - table of contents will be rendered
+menu, page - table of contents will be rendered
             in both the page and the menu positions
           
 
@@ -697,8 +697,8 @@
 Direct linking
 
           In earlier versions of Forrest (and in similar systems), there has
-          been only one URI space: that of the generated site.  If index.xml wants to
-          link to todo.xml then index.xml would use
+          been only one URI space: that of the generated site.  If index.xml wants to
+          link to todo.xml then index.xml would use
         
            <link href="todo.html">to-do list<link>
@@ -729,8 +729,8 @@
           
 todo
           
-identifies the content in todo.xml by reference to a
-            "node" of content declared in site.xml
+
identifies the content in todo.xml by reference to a
+            "node" of content declared in site.xml
 
         
 
@@ -743,13 +743,13 @@
 
 Resolving site: URIs
 
-            So how does "site:todo" get resolved?  A full answer
+            So how does "site:todo" get resolved?  A full answer
             is provided in the implementation
-            section.  Essentially, the "todo" part has
-            "/site//" prepended, and "/@href" appended, to
-            form the string "/site//todo/@href".  This is
-            then used as an XPath expression in site.xml to identify the string
-            replacement, in this case "todo.html"
+            section.  Essentially, the "todo" part has
+            "/site//" prepended, and "/@href" appended, to
+            form the string "/site//todo/@href".  This is
+            then used as an XPath expression in site.xml to identify the string
+            replacement, in this case "todo.html"
           
 
             Thus by modifying the XPath prefix and suffix, almost any XML
@@ -759,33 +759,33 @@
 
Note
 
             Actually, the XPath is applied to XML generated dynamically from
-            site.xml.  The generated XML has each "@href" fully expanded ("absolutized")
+            site.xml.  The generated XML has each "@href" fully expanded ("absolutized")
             and dot-dots (..) added as needed ("relativized").
           
 

 
             Notice that the "//" allows us any degree of specificity when linking.
-            In the sample site.xml above, both "site:new_content_type" and
-            "site:about/your-project/new_content_type" identify the
+            In the sample site.xml above, both "site:new_content_type" and
+            "site:about/your-project/new_content_type" identify the
             same node.  It is up to you to decide how specific to make links.  One
-            nice benefit of link "ambiguity" is that site.xml can be reorganized
+            nice benefit of link "ambiguity" is that site.xml can be reorganized
             without breaking links.  For example, "new_content_type" currently
             identifies a node in "your-project".  By leaving that fact unspecified
-            in "site:new_content_type" we are free to make
+            in "site:new_content_type" we are free to make
             "new_content_type" its own XML file, or a node in another file, in
             another category.
           
 
 ext: URIs: linking to external URLs
 
-            The "ext:" scheme was created partly to demonstrate the
+            The "ext:" scheme was created partly to demonstrate the
             ease with which new schemes can be defined, and partly for practical
-            use. The "ext:" URIs identify nodes in site.xml below the
+            use. The "ext:" URIs identify nodes in site.xml below the
             <external-refs> node.  By convention, nodes here link to URLs
             outside the website, and are not listed in the menu generated from
-            the site.xml file.
+            the site.xml file.
           
-Here is a site.xml snippet illustrating "external-refs":
+Here is a site.xml snippet illustrating "external-refs":
  <site>
   ...
@@ -806,30 +806,30 @@
           
 
 
-            The general rules of site.xml and "site:" linking apply.
+            The general rules of site.xml and "site:" linking apply.
             Specifically, the "@href" aggregation makes defining large numbers of
             related URLs easy.
           
 
 Theory: source URIs
 
-            The "site:" URIs like "site:todo" are examples of
+            The "site:" URIs like "site:todo" are examples of
             "source" URIs, in contrast to the more usual
-            foo.html style URIs, which we here call
+            foo.html style URIs, which we here call
             "destination" URIs.  This introduces an important concept: that
             the "source" URI space exists and is independent of that of the
             generated site.  Furthermore, URIs (i.e. links) are first-class objects,
             on par with XML documents, in that just as XML content is transformed,
             so are the links.  Within the source URI space, we can have all sorts of
             interesting schemes (person: mail: google: java: etc). These will
-            all be translated into plain old "http:" or relative URIs
+            all be translated into plain old "http:" or relative URIs
             in the destination URI space, just like exotic XML source formats are
             translated into plain old HTML in the output.
           
 
 Future schemes
 
-            So far, the "site:" and "ext:" schemes are defined.
+            So far, the "site:" and "ext:" schemes are defined.
             To give you some ideas on other things we'd like to implement (and
             wouldd welcome help to implement) here are a few possibilities.
           
@@ -843,10 +843,10 @@
               
 java
               java:org.apache.proj.SomeClass
-              ../../apidocs/org/apache/proj/SomeClass.html
+              ../../apidocs/org/apache/proj/SomeClass.html
               
                 Links to documentation for a Java class (typically generated by
-                javadoc).
+                javadoc).
               
             
 
@@ -855,9 +855,9 @@
               
 mail
               mail::<Message-Id>
-              http://marc.theaimsgroup.com?t=12345678
+              http://marc.theaimsgroup.com?t=12345678
               
-                Links to an email, identified by its Message-Id
+                Links to an email, identified by its Message-Id
                 header. Any mail archive website could be used.
               
             
@@ -867,7 +867,7 @@
               
 search
               search:<searchterm>
-              http://www.google.com/search?q=searchterm
+              http://www.google.com/search?q=searchterm
               Link to set of results from a search engine
             
 
@@ -876,10 +876,10 @@
               
 person
               person:JT, person:JT/blog etc
-              mailto:jefft<at>apache.org,
-                http://www.webweavertech.com/jefft/weblog/
+              mailto:jefft<at>apache.org,
+                http://www.webweavertech.com/jefft/weblog/
               
-                A "person:" scheme could be used, say, to insert an
+                A "person:" scheme could be used, say, to insert an
                 automatically obfuscated email address, or link to a URI in some
                 way associated with that person.
               
@@ -889,10 +889,10 @@
 
 
             There are even more possibilities in specific environments.  In an
-            intranet, a "project:XYZ" scheme could identify company
+            intranet, a "project:XYZ" scheme could identify company
             project pages.  In a project like Apache
               Ant, each Task could be identified with
-            task:<taskname>, e.g. task:pathconvert.
+            task:<taskname>, e.g. task:pathconvert.
           
 
     
@@ -900,13 +900,13 @@
 Concept
 
 
-        The "site:" scheme and associated ideas for site.xml were
+        The "site:" scheme and associated ideas for site.xml were
         originally described in the 'linkmap' RT
           email to the forrest-dev list (RT means 'random thought'; a
         Cocoon invention).   Only section 2 has been implemented, and there is
         still significant work required to implement the full system
         described.  In particular, there is much scope for automating the
-        creation of site.xml (section 4).  However, what is currently implemented
+        creation of site.xml (section 4).  However, what is currently implemented
         gains most of the advantages of the system.
       
 

Modified: forrest/site/docs_0_60/project-sitemap.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_60/project-sitemap.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_60/project-sitemap.html (original)
+++ forrest/site/docs_0_60/project-sitemap.html Sun Dec 18 17:31:25 2005
@@ -318,7 +318,7 @@
 
 How does it work?
 
-If a project has a sitemap.xmap file in it's 
+
If a project has a sitemap.xmap file in it's 
       documentation dir, that gets mounted automatically by Forrest and 
       becomes part of the processing: it is a preprocessing step, and 
       is the first one to handle the request. Because of this it can 

Modified: forrest/site/docs_0_60/searching.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_60/searching.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_60/searching.html (original)
+++ forrest/site/docs_0_60/searching.html Sun Dec 18 17:31:25 2005
@@ -312,15 +312,15 @@
 	functionality is implemented on Google's end, you do not need
 	any additional capability on your Forrest server (which may
 	well be a simple static web server serving content generated
-	with forrest site).
+	with forrest site).
 To use Google SiteSearch in your Forrest application, open
-	your skinconf.xml file. By default this file is
-	in the src/documentation subdirectory of your
-	Forrest repository root. Find the <search>
+	your skinconf.xml file. By default this file is
+	in the src/documentation subdirectory of your
+	Forrest repository root. Find the <search>
 	element; it should be near the top of the file. If the element
 	does not exist, create it below the
-	<skinconfig> opening tag. If there is any
-	attribute named provider, remove it. The element
+	<skinconfig> opening tag. If there is any
+	attribute named provider, remove it. The element
 	should look similar to this:
 <search name="MyProject"
 	domain="myproject.com"/>
@@ -345,26 +345,26 @@
 	entirely in Java. To use Lucene-based search with your Forrest
 	documentation, you will need to run Forrest in a Java servlet
 	environment (such as Tomcat or Jetty). Lucene-based searching
-	will not work in a static site generated with the 'forrest
+	will not work in a static site generated with the 'forrest
 	  site' command.
 In order to enable Lucene-based full-text search in your
 	Forrest application, you must first edit your
-	skinconf.xml file. Locate the
-	<search> element. If the element does not
+	skinconf.xml file. Locate the
+	<search> element. If the element does not
 	exist, insert it right underneath the
-	<skinconfig> opening tag. Add an attribute
-	named provider with a value of
-	lucene, so that the element looks similar to
+	<skinconfig> opening tag. Add an attribute
+	named provider with a value of
+	lucene, so that the element looks similar to
 	this:
 <search name="MyProject" domain="myproject.com"
 	provider="lucene"/>
 Next, create and run your Forrest webapp. This may mean
-	simply invoking forrest run, or building and
-	bundling a servlet webapp (with forrest webapp),
+	simply invoking forrest run, or building and
+	bundling a servlet webapp (with forrest webapp),
 	and then deploying it to your servlet container.
 You can now build a Lucene search index by pointing your web
 	browser at
-	http://localhost:8888/lucene-update.html. This
+	http://localhost:8888/lucene-update.html. This
 	generates the search index and provides some information about
 	the index generation process.
 
@@ -372,7 +372,7 @@
 You may have to substitute a different hostname, port, or
 	path, depending on your configuration. The path mentioned here
 	reflects Forrest's default settings when invoked as
-	forrest run.
+	forrest run.
 
 Now you can utilize the full-text search box, located in the
 	top-right corner of the rendered Forrest pages. Search results
@@ -399,8 +399,8 @@
 	usable servlet-capable web server at your disposal (meaning
 	you can't use Lucene, either).
 To disable full-text search completely, open the
-	skinconf.xml file and remove (or comment out) the
-	entire <search> element.
+	skinconf.xml file and remove (or comment out) the
+	entire <search> element.
 
   
 

Modified: forrest/site/docs_0_60/sitemap-ref.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_60/sitemap-ref.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_60/sitemap-ref.html (original)
+++ forrest/site/docs_0_60/sitemap-ref.html Sun Dec 18 17:31:25 2005
@@ -386,18 +386,18 @@
       
 
         You can add pre-processing sitemaps to your project
-        src/documentation directory (or wherever
-        ${project.sitemap-dir} points to). Any match that
+        src/documentation directory (or wherever
+        ${project.sitemap-dir} points to). Any match that
         is not handled, passes through to be handled by the default Forrest
         sitemaps - obviously extremely powerful. The capability is described
         in 
         "Using project sitemaps".
       
 
-        Another way to experiment with the sitemap is to do 'forrest
+        Another way to experiment with the sitemap is to do 'forrest
         run' on a Forrest-using site.  Changes to the core
-        *.xmap files will now be immediately visible
-        at >http://localhost:8888/
+        *.xmap files will now be immediately visible
+        at >http://localhost:8888/
       
 
 
@@ -462,7 +462,7 @@
 
           
 raw.xmap
-          Serves files located in src/documentation/content/
+          Serves files located in src/documentation/content/
             that are not to be modified by Forrest.
         
 
@@ -487,7 +487,7 @@
 status.xmap
           Generates changes and 
           todo pages from a single
-            status.xml in the project root.
+            status.xml in the project root.
           
         
 
@@ -559,13 +559,13 @@
         format.
       
 
-        Source pipelines always have a ".xml" extension.  Thus, 
+        Source pipelines always have a ".xml" extension.  Thus, 
         index.xml gives you the XML source for the
         index page.  Likewise, faq.xml gives you XML
         for the FAQ (transformed from FAQ syntax), and 
         changes.xml returns XML from the status.xml file.
-        Take any page, and replace its extension (.html or
-        .pdf) with .xml and you'll have the Source
+        Take any page, and replace its extension (.html or
+        .pdf) with .xml and you'll have the Source
         XML.
       
 
@@ -590,8 +590,8 @@
 
forrest.xmap
 
           Most of the usual Source pipelines are defined in
-          forrest.xmap which is the default (fallback) handler for
-          **.xml pages. The forrest.xmap uses the 
+          forrest.xmap which is the default (fallback) handler for
+          **.xml pages. The forrest.xmap uses the 
           SourceTypeAction to determine the type of XML
           it is processing, and converts it to document-v13 if necessary.
         
@@ -611,8 +611,8 @@
 
 Other source pipelines
 As mentioned above, all non-core Source pipelines are distributed in
-          independent *.xmap files.  There is a block of
-          sitemap.xmap which simply delegates certain requests to
+          independent *.xmap files.  There is a block of
+          sitemap.xmap which simply delegates certain requests to
           these subsitemaps:
        <!-- Body content -->
@@ -649,14 +649,14 @@
             specific about which URLs it handles, and relies on the caller (the
             section listed above) to only pass relevant requests to it.  We term
             this "binding a URL" to a pipeline.
-For instance, the main pipeline in faq.xmap matches
-            **.xml, but only **faq.xml requests are
+
For instance, the main pipeline in faq.xmap matches
+            **.xml, but only **faq.xml requests are
             sent to it.
 This "late binding" is useful, because the whole URL space is
-            managed in sitemap.xmap and not spread over lots of
-            *.xmap files.  For instance, say you wish all *.xml
-            inside a "faq/" directory to be processed as FAQs.  Just
-            override sitemap.xmap and redefine the relevant source
+            managed in sitemap.xmap and not spread over lots of
+            *.xmap files.  For instance, say you wish all *.xml
+            inside a "faq/" directory to be processed as FAQs.  Just
+            override sitemap.xmap and redefine the relevant source
             matcher:
          <map:match pattern="**faq.xml">
@@ -669,7 +669,7 @@
 Output pipelines
 
 
-        To recap, we now have a *.xml pipeline defined for each
+        To recap, we now have a *.xml pipeline defined for each
         page in the site, emitting standardized XML.  These pipeline definitions
         are located in various *.xmap files, notably forrest.xmap
       
@@ -683,7 +683,7 @@
           Easiest case first; PDFs don't require menus or headers, so we can
           simply transform our intermediate format into XSL:FO, and from there
           to PDF.  This is done by the following matcher in
-          sitemap.xmap ...
+          sitemap.xmap ...
         
  1   <map:match type="regexp" pattern="^(.*?)([^/]*).pdf$">
@@ -700,11 +700,11 @@
 
           
 The first line uses a matching regexp to break the URL into
-            directory (.*?) and filename
-            ([^/]*) parts.
+            directory (.*?) and filename
+            ([^/]*) parts.
           
 We then generate XML from a Source
-              pipeline, with the URL cocoon:/{1}{2}.xml
+              pipeline, with the URL cocoon:/{1}{2}.xml
 
           
 We then expand any XInclude statements..
@@ -720,8 +720,8 @@
 HTML output
 Generating HTML pages is more complicated, because we have to merge
           the page body with a menu and tabs, and then add a header and footer.
-          Here is the *.html matcher in
-          sitemap.xmap ...
+          Here is the *.html matcher in
+          sitemap.xmap ...
            <map:match pattern="*.html">
             <map:aggregate element="site">
@@ -740,7 +740,7 @@
           aggregating body-index.html and
           menu-index.html and 
           tab-index.html and then applying the
-          site2xhtml.xsl stylesheet to the result.
+          site2xhtml.xsl stylesheet to the result.
         
 
           There is a nearly identical matcher for HTML files in subdirectories:
@@ -791,7 +791,7 @@
 

             
 We then apply a custom-written
-              IdGeneratorTransformer, which ensures that every
+              IdGeneratorTransformer, which ensures that every
               <section> has an "id" attribute if one is not supplied, by generating one from the
               <title> if necessary.  For example, <idgen> will
               transform:
@@ -810,9 +810,9 @@
               ...
             
             
-Later, the document2html.xsl stylesheet will create
+
Later, the document2html.xsl stylesheet will create
               an <a name> element for every section, allowing this section to
-              be referred to as index.html#How+to+boil+eggs.
+              be referred to as index.html#How+to+boil+eggs.
           
 
           
@@ -827,7 +827,7 @@
 
 
 Page menu
-In the sitemap.xmap file, the matcher generating HTML for the menu is:
+In the sitemap.xmap file, the matcher generating HTML for the menu is:
        <map:match pattern="**menu-*.html">
         <map:generate src="cocoon:/{1}book-{2}.html"/>
@@ -840,7 +840,7 @@
       
 We get XML from a "book" pipeline, 
         rewrite links, and apply the
-          book2menu.xsl stylesheet to generate HTML.
+          book2menu.xsl stylesheet to generate HTML.
 How the menu XML is actually generated (the *book-*.html pipeline) is
           sufficiently complex to require a 
           section of its own.
@@ -857,23 +857,23 @@
        </map:call>
      </map:match>
            
-All the smarts are in the tab2menu.xsl stylesheet, which
+
All the smarts are in the tab2menu.xsl stylesheet, which
           needs to choose the correct tab based on the current path.  Currently,
           a "longest matching path" algorithm is implemented.  See the
-          tab2menu.xsl stylesheet for details.
+          tab2menu.xsl stylesheet for details.
 
 
     
 
 Menu XML generation
 
-The "book" pipeline is defined in sitemap.xmapas:
+The "book" pipeline is defined in sitemap.xmapas:
          <map:match pattern="**book-*.html">
           <map:mount uri-prefix="" src="menu.xmap" check-reload="yes" />
         </map:match>
         
-Meaning that it is defined in the menu.xmap file.  In there we find
+
Meaning that it is defined in the menu.xmap file.  In there we find
         the real definition, which is quite complicated, because there are three
         supported menu systems (see menus and
           linking).  We will not go through the sitemap itself
@@ -884,7 +884,7 @@
           root-relative.
         
 

-Depending on the forrest.menu-scheme property, we
+
Depending on the forrest.menu-scheme property, we
             now apply one of the two algorithms for choosing a set of menu links
             (described in menu
               generation):
@@ -902,12 +902,12 @@
               
 
                 For example, say our current page's path is
-                community/howto/index.html.  In
-                site.xml we look for the node with this
-                "href" and discover its "tab" attribute
-                value is "howtos".  We then prune the
-                site.xml-derived content to contain only nodes with
-                tab="howtos".
+                community/howto/index.html.  In
+                site.xml we look for the node with this
+                "href" and discover its "tab" attribute
+                value is "howtos".  We then prune the
+                site.xml-derived content to contain only nodes with
+                tab="howtos".
               
               
 
@@ -927,7 +927,7 @@
 

               
 For "directory" menu generation, we simply use an
-                XPathTransformer to include only pages in the
+                XPathTransformer to include only pages in the
                 current page's directory, or below:
               
 @@ -937,10 +937,10 @@
                 
               
 
-                Here, the "{1}" is the directory part of the current
+                Here, the "{1}" is the directory part of the current
                 page.  So if our current page is
-                community/howto/index.html then "{1}" will
-                be community/howto/ and the transformer will
+                community/howto/index.html then "{1}" will
+                be community/howto/ and the transformer will
                 include all nodes in that directory.
               
             
@@ -948,18 +948,18 @@
           
 
           
-We now have a site.xml subset relevant to our current
+
We now have a site.xml subset relevant to our current
             page.
         
 
         
-The "href" nodes in this are then made relative to the
+
The "href" nodes in this are then made relative to the
           current page.
         
-The XML is then transformed into a legacy "book.xml"
+
The XML is then transformed into a legacy "book.xml"
           format, for compatibility with existing stylesheets, and this XML
           format is returned (hence the name of the matcher:
-          **book-*.html).
+          **book-*.html).
       
 
 
@@ -968,7 +968,7 @@
 
 Link rewriting
 
-In numerous places in sitemap.xmap you will see the
+
In numerous places in sitemap.xmap you will see the
         "linkrewriter" transformer in action.  For example:
 <map:transform type="linkrewriter" src="cocoon:/{1}linkmap-{2}.html"/>
 This statement is Cocoon's linking system in action.  A full
@@ -977,7 +977,7 @@
 
 
Cocoon foundations: Input Modules
 
-          The implementation of site: linking is heavily based on
+          The implementation of site: linking is heavily based on
           Cocoon Input Modules, a
           little-known but quite powerful aspect of Cocoon.  Input Modules are
           generic Components which simply allow you to look up a value with a
@@ -985,21 +985,21 @@
           querying an underlying data source.
         
 
-          In particular, Cocoon contains an XMLFileModule, which
+          In particular, Cocoon contains an XMLFileModule, which
           lets one look up the value of an XML node, by interpreting the key as
           an XPath expression.  Cocoon also has a
-          SimpleMappingMetaModule, which allows the key to be
+          SimpleMappingMetaModule, which allows the key to be
           rewritten before it is used to look up a value.
         
 
-          The idea for putting these together to rewrite "site:"
+          The idea for putting these together to rewrite "site:"
           links was described in this
             thread. The idea is to write a Cocoon Transformer that
           triggers on encountering <link
-          href="scheme:address">, and interprets the
-          scheme:address internal URI as
-          inputmodule:key.  The transformer then uses the named
-          InputModule to look up the key value. The scheme:address
+          href="scheme:address">, and interprets the
+          scheme:address internal URI as
+          inputmodule:key.  The transformer then uses the named
+          InputModule to look up the key value. The scheme:address
           URI is then rewritten with the found value.  This transformer was
           implemented as 
           LinkRewriterTransformer,
@@ -1008,7 +1008,7 @@
 
 
Implementing "site:" rewriting
 
-          Using the above components, "site:" URI rewriting is
+          Using the above components, "site:" URI rewriting is
           accomplished as follows.
         
 
@@ -1034,26 +1034,26 @@
             
 
 linkmap will provide access to the contents of
-              site.xml; for example, linkmap:/site/about/index/@href
+              site.xml; for example, linkmap:/site/about/index/@href
               would return the value "index.html".
             
 
 site provides a "mask" over
-              linkmap such that site:index expands
-              to linkmap:/site//index/@href
+              linkmap such that site:index expands
+              to linkmap:/site//index/@href
             
 
             
 
 ext provides another "mask" over
-              linkmap, such that ext:ant would
-              expand to linkmap:/site/external-refs//ant/@href
+              linkmap, such that ext:ant would
+              expand to linkmap:/site/external-refs//ant/@href
             
 
           
 
 However at the moment, we have only declared the input modules.
-            They will be configured in sitemap.xmap as described in
+            They will be configured in sitemap.xmap as described in
             the next section.
 
 sitemap.xmap
@@ -1110,39 +1110,39 @@
                   <file src="{src}" reloadable="false" />
               </input-module>
               
-The "{src}" text is expanded to the value of the
-                "src" attribute in the "linkrewriter"
-                instance, namely "cocoon:/{1}linkmap-{2}.html"
-                Thus the linkmap module reads dynamically
+
The "{src}" text is expanded to the value of the
+                "src" attribute in the "linkrewriter"
+                instance, namely "cocoon:/{1}linkmap-{2}.html"
+                Thus the linkmap module reads dynamically
                 generated XML specific to the current request.
             
 
             
 
               
-One level out, we configure the "site" and
-                "ext" input modules, to map onto our dynamically
-                configured "linkmap" module.
+One level out, we configure the "site" and
+                "ext" input modules, to map onto our dynamically
+                configured "linkmap" module.
             
 
             
 
               
 Then at the outermost level, we configure the
-                "linkrewriter" transformer.  First we tell it which
+                "linkrewriter" transformer.  First we tell it which
                 attributes to consider rewriting:
               
                  <link-attrs>href src</link-attrs>
                 <schemes>site ext</schemes>
               
-So, "href" and "src" attributes starting
-                with "site:" or "ext:" are rewritten.
+So, "href" and "src" attributes starting
+                with "site:" or "ext:" are rewritten.
 
               
-By nesting the "site" and "ext" input
-                modules in the "linkrewriter" configuration, we tell
-                "linkrewriter" to use these two input modules when
+
By nesting the "site" and "ext" input
+                modules in the "linkrewriter" configuration, we tell
+                "linkrewriter" to use these two input modules when
                 rewriting links.
             
 
@@ -1150,20 +1150,20 @@
 
 
             The end result is that, for example, the source XML for the
-            community/body-index.html page has its links rewritten
+            community/body-index.html page has its links rewritten
             by an XMLFileModule reading XML from
-            cocoon:/community/linkmap-index.html
+            cocoon:/community/linkmap-index.html
           
 
 
 Dynamically generating a linkmap
 
             Why do we need this "linkmap" pipeline generating dynamic XML from
-            site.xml, instead of just using site.xml directly?  The reasons are described
+            site.xml, instead of just using site.xml directly?  The reasons are described
             in the linkmap RT: we need to
             concatenate @hrefs and add dot-dots to the paths, depending on which
             directory the linkee is in.  This is done with the following
-            pipelines in linkmap.xmap ...
+            pipelines in linkmap.xmap ...
           
  <!-- site.xml with @href's appended to be context-relative. -->

Modified: forrest/site/docs_0_60/todo.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_60/todo.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_60/todo.html (original)
+++ forrest/site/docs_0_60/todo.html Sun Dec 18 17:31:25 2005
@@ -316,7 +316,7 @@
         
         This info can then be made public to the sitemap (via XMLFileModule
         attributes) and the stylesheets (through
-        document(cocoon:/...) calls or inlined with source XML).
+        document(cocoon:/...) calls or inlined with source XML).
          → open
 
 [code] 

Modified: forrest/site/docs_0_60/upgrading_06.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_60/upgrading_06.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_60/upgrading_06.html (original)
+++ forrest/site/docs_0_60/upgrading_06.html Sun Dec 18 17:31:25 2005
@@ -378,7 +378,7 @@
 Run a clean target after upgrade
 
 To avoid any issue with old classes being loaded, run a
-        'forrest clean' in your project directory, after you
+        'forrest clean' in your project directory, after you
         upgraded to this version.
       
 
@@ -393,7 +393,7 @@
 
       Take advantage of the separation of concerns. In a new workspace,
       create a fresh
-      'forrest seed' site, then tweak its forrest.properties
+      'forrest seed' site, then tweak its forrest.properties
       and skinconf.xml until it reflects your old site.
       When it is ready, replace your project's skinconf.xml and
       forrest.properties files.
@@ -440,10 +440,10 @@
       them synchonised. This will enable hassle-free update to
       future Forrest versions.
 
-        If your old project did not use any customised *.xmap 
+        If your old project did not use any customised *.xmap 
         files, then your upgrade process will be easy (you can safely skip this
         section).
-If your project did use custom *.xmaps, with matchers for 
+
If your project did use custom *.xmaps, with matchers for 
         special circumstances (for example special doctypes that you 
         were handling) then you will need to be prepared to make some changes. 
         Hopefully with the new functionality of Forrest, you can do away with 
@@ -457,16 +457,16 @@
       there is now an extension mechanism for the sitemap (as opposed to 
       a replacement mechanism).
 When upgrading to Forrest 0.6 you need to copy customised matchers 
-      in any of your projects *.xmap files into your projects 
-      sitemap.xmap file. Any matchers in your project 
-      *.xmap files that duplicate ones in Forrests own 
-      *.xmaps can now be removed. This will ensure that future 
+      in any of your projects *.xmap files into your projects 
+      sitemap.xmap file. Any matchers in your project 
+      *.xmap files that duplicate ones in Forrests own 
+      *.xmaps can now be removed. This will ensure that future 
       enhancements to these matchers in Forrest will automatically be included 
       in your project.
 Move your old sitemap out of the way, copy a default one from a fresh
       'forrest seed', and add the specific matches that you require.
 The good news is that this process makes upgrading to future versions
-      of Forrest much simpler, because your project *.xmap files will 
+      of Forrest much simpler, because your project *.xmap files will 
       contain only your customisations. As a result there will no longer be a
       need to merge your custom xmaps with the updated ones in upcoming versions of 
       Forrest.
@@ -495,8 +495,8 @@
 
       Various capabilities have been added to the skinconfig.
       See the new descriptions in the 
-      'forrest seed' site
-      src/documentation/skinconf.xml and synchronise yours.
+      'forrest seed' site
+      src/documentation/skinconf.xml and synchronise yours.
       
 For example, to use different colors (e.g. the light blue of the old
       krysalis skin), CSS colors can be specified in skinconf.xml
@@ -512,7 +512,7 @@
 
forrest.antproxy.xml is obsolete in favor of Ant's <import> task
 
 
-      Projects that use forrest.antproxy.xml via an Ant build
+      Projects that use forrest.antproxy.xml via an Ant build
       task to invoke Forrest, will receive
       an error message directing them to this document.
       Please see the Invoking
@@ -529,7 +529,7 @@
       The .ehtml input file format has been deprecated and will likely be
       removed in the next release.
       Please convert all .ehtml files to .html files.
-      If you do 'forrest seed' there is a sample html source file.
+      If you do 'forrest seed' there is a sample html source file.
       

 

 

Modified: forrest/site/docs_0_60/validation.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_60/validation.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_60/validation.html (original)
+++ forrest/site/docs_0_60/validation.html Sun Dec 18 17:31:25 2005
@@ -309,7 +309,7 @@
         By default, Forrest will validate your XML before generating
         HTML or a webapp from it, and fail if any XML files are not valid.
         Validation can be performed manually by doing
-        'forrest validate' in the project root directory.
+        'forrest validate' in the project root directory.
       
 
         For an XML file to be valid, it must have a document type
@@ -323,7 +323,7 @@
         project.  In validated sections, it is possible for projects to specify
         exactly what files they want (and don't want) validated.  Forrest
         validation is controlled through a set of properties in
-        forrest.properties:
+        forrest.properties:
       
  ##############
@@ -350,18 +350,18 @@
       
 
         For example, to avoid validating
-        ${project.xdocs-dir}/slides.xml and everything inside the
-        ${project.xdocs-dir}/manual/ directory, add this to
-        forrest.properties:
+        ${project.xdocs-dir}/slides.xml and everything inside the
+        ${project.xdocs-dir}/manual/ directory, add this to
+        forrest.properties:
       
 forrest.validate.xdocs.excludes=slides.xml, manual/**
 
 Note
 
-        The failonerror properties only work for files validated
+        The failonerror properties only work for files validated
         with Ant's <xmlvalidate> and not (yet) for those validated
-        with <jing>, where failonerror defaults to
-        true.
+        with <jing>, where failonerror defaults to
+        true.
       
 
 
@@ -373,12 +373,12 @@
 
         Forrest provides an OASIS Catalog
         [see tutorial]
-        forrest/src/core/context/resources/schema/catalog.xcat
+        forrest/src/core/context/resources/schema/catalog.xcat
         as a means of associating public identifiers
-        (e.g. -//APACHE//DTD Documentation V1.1//EN above) with DTDs.
+        (e.g. -//APACHE//DTD Documentation V1.1//EN above) with DTDs.
         If you add a new content type, you
-        should add the DTD to ${project.schema-dir}/dtd/ and add
-        an entry to the ${project.schema-dir}/catalog.xcat file.  This
+        should add the DTD to ${project.schema-dir}/dtd/ and add
+        an entry to the ${project.schema-dir}/catalog.xcat file.  This
         section describes the details of this process.
       
 
@@ -408,13 +408,13 @@
         
 
           The document-v13 entities are defined in a reusable 'module':
-          forrest/src/core/context/resources/schema/dtd/document-v13.mod
+          forrest/src/core/context/resources/schema/dtd/document-v13.mod
           The
-          forrest/src/core/context/resources/schema/dtd/document-v13.dtd
+          forrest/src/core/context/resources/schema/dtd/document-v13.dtd
           file provides a full description and basic example of how to pull in
           modules.  In our example, our DTD reuses modules
-          common-charents-v10.mod and
-          document-v13.mod.  Here is the full DTD, with
+          common-charents-v10.mod and
+          document-v13.mod.  Here is the full DTD, with
           explanation to follow.
         
 @@ -489,20 +489,20 @@
 <!-- =============================================================== -->
         
 This custom DTD should be placed in your project resources
-        directory at src/documentation/resources/schema/dtd/
+        directory at src/documentation/resources/schema/dtd/
 
 
           The <!ENTITY % ... > blocks are so-called 
           parameter
             entities.  They are like macros, whose content will be
           inserted when a parameter-entity reference, like
-          %common-charents; or %document; is
+          %common-charents; or %document; is
           inserted.
         
 
           In our DTD, we first pull in the 'common-charents' entity, which
           defines character symbol sets.  We then define the 'document'
-          entity.  However, before the %document; PE reference, we
+          entity.  However, before the %document; PE reference, we
           first override the 'local.section' entity.  This is a hook into
           document-v13.mod.  By setting its value to '|release', we declare
           that our <release> element is to be allowed wherever "local
@@ -534,7 +534,7 @@
           "download-v10.dtd">
         
 
-          We only care about the quoted section after PUBLIC, called
+          We only care about the quoted section after PUBLIC, called
           the "public identifier", which globally identifies our document type.
           We cannot rely on the subsequent "system identifier" part
           ("download-v10.dtd"), because as a relative reference it is liable to
@@ -551,11 +551,11 @@
 
 

           Forrest provides a standard catalog file at
-          forrest/src/core/context/resources/schema/catalog.xcat
+          forrest/src/core/context/resources/schema/catalog.xcat
           for the document
           types that Forrest provides.  Projects can augment this with their
           own catalog file located in
-          ${project.schema-dir}/catalog.xcat
+          ${project.schema-dir}/catalog.xcat
         
 
 
@@ -573,24 +573,24 @@
 

           The format is described in the
           spec, and is fairly simple and very powerful.
-          The "public" elements map
+          The "public" elements map
           a public identifier to a DTD (relative to the catalog file).
         
 
-          Next specify the full path to your catalog.xcat in the
-          src/documentation/classes/CatalogManager.properties file.
+          Next specify the full path to your catalog.xcat in the
+          src/documentation/classes/CatalogManager.properties file.
           Cocoon needs this file when it starts to run. A template file is
           provided in the "fresh-site" when you do the
-          'forrest seed' to commence a new project.
+          'forrest seed' to commence a new project.
         
 
           We now have a custom DTD and a catalog mapping which lets both
           Forrest and Cocoon
-          locate the DTD.  Now if we were to run 'forrest validate'
+          locate the DTD.  Now if we were to run 'forrest validate'
           our download file would validate along with all the others.  If
-          something goes wrong, try running 'forrest -v validate' to
+          something goes wrong, try running 'forrest -v validate' to
           see the error in more detail. Remember to raise the "verbosity"
-          level in cocoon.xconf if you suspect problems
+          level in cocoon.xconf if you suspect problems
           with your catalog.
         
 
@@ -601,8 +601,8 @@
 
 
         Look at the source of this document
-        (xdocs/docs/validation.xml) and see how the entity set
-        "Numeric and Special Graphic" is declared in the
+        (xdocs/docs/validation.xml) and see how the entity set
+        "Numeric and Special Graphic" is declared in the
         document type declaration.
       
 
@@ -644,10 +644,10 @@
       

         The RNG grammars to do this are located in the
-        src/core/context/resources/schema/relaxng directory.
+        src/core/context/resources/schema/relaxng directory.
         If you want to
         know more about this, and perhaps extend it for your own use, then
-        see src/core/context/resources/schema/relaxng/README.txt
+        see src/core/context/resources/schema/relaxng/README.txt
         and the Ant targets in the various build.xml files.