forrest-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cross...@apache.org
Subject svn commit: r357603 [5/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 GMT
Modified: forrest/site/docs_0_70/linking.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_70/linking.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_70/linking.html (original)
+++ forrest/site/docs_0_70/linking.html Sun Dec 18 17:31:25 2005
@@ -390,7 +390,7 @@
 <div class="section">
 <p>
         This document describes Forrest's internal URI space; how it is managed
-        with the "<span class="codefrag ">site.xml</span>" configuration file, how menus are generated,
+        with the "<span class="codefrag">site.xml</span>" configuration file, how menus are generated,
         and how various link schemes (site: and ext:) operate.
         An overview of the implementation is also provided.
       </p>
@@ -401,9 +401,9 @@
 <h2 class="underlined_10">site.xml</h2>
 <div class="section">
 <p>
-        The "<span class="codefrag ">site.xml</span>" configuration file is what we would call a "site map"
+        The "<span class="codefrag">site.xml</span>" configuration file is what we would call a "site map"
         if Cocoon hadn't already claimed that term. 
-        The "<span class="codefrag ">site.xml</span>" is a loosely structured XML file, acting as a map of the
+        The "<span class="codefrag">site.xml</span>" 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:
@@ -416,17 +416,17 @@
 <li>A specific page, e.g. "the FAQ page"</li>
         
 <li>A specific section in a page, e.g. the "general" section of the FAQ
-          page (identified by <span class="codefrag ">id="general"</span> attribute)</li>
+          page (identified by <span class="codefrag">id="general"</span> attribute)</li>
       
 </ul>
 <p>
-        In addition to providing fine-grained addressing of site info, the <span class="codefrag ">site.xml</span>
+        In addition to providing fine-grained addressing of site info, the <span class="codefrag">site.xml</span>
         allows <em>metadata</em> to be associated with each node, using
-        attributes or child elements.  Most commonly, a <span class="codefrag ">label</span>
+        attributes or child elements.  Most commonly, a <span class="codefrag">label</span>
         attribute is used to provide a text description of the node.
       </p>
 <p>
-        There are currently two applications of <span class="codefrag ">site.xml</span>
+        There are currently two applications of <span class="codefrag">site.xml</span>
       
 </p>
 <dl>
@@ -436,21 +436,21 @@
 </dt>
         
 <dd>
-<span class="codefrag ">site.xml</span> is used to generate the menus for the HTML website.</dd>
+<span class="codefrag">site.xml</span> is used to generate the menus for the HTML website.</dd>
         
 <dt>
 <a href="#indirect-linking">Indirect linking</a>
 </dt>
         
 <dd>
-<span class="codefrag ">site.xml</span> provides a basic aliasing mechanism for linking, e.g. one
+<span class="codefrag">site.xml</span> provides a basic aliasing mechanism for linking, e.g. one
           can write &lt;link href="site:v0.70//changes"&gt; from anywhere in the site, and
           link to the "changes" information node (translated to changes.html).
           More on this below.</dd>
       
 </dl>
 <p>
-        Here is a sample <span class="codefrag ">site.xml</span> ...
+        Here is a sample <span class="codefrag">site.xml</span> ...
       </p>
 <pre class="code">
 &lt;?xml version="1.0"?&gt;
@@ -511,25 +511,25 @@
 <ul>
         
 <li>The root element must be "site", and normal content should be in the
-          namespace <span class="codefrag ">http://apache.org/forrest/linkmap/1.0</span> (Feel
+          namespace <span class="codefrag">http://apache.org/forrest/linkmap/1.0</span> (Feel
           free to mix in your own content (RDF, dublin core, etc) under new
           namespaces)</li>
         
-<li>Element names are used as identifiers.  The "<span class="codefrag ">foo</span>" in
-          "<span class="codefrag ">site:foo</span>" must therefore be a valid NMTOKEN.</li>
+<li>Element names are used as identifiers.  The "<span class="codefrag">foo</span>" in
+          "<span class="codefrag">site:foo</span>" must therefore be a valid NMTOKEN.</li>
         
-<li>Elements with <span class="codefrag ">href</span> attributes can be used as identifiers
-          in "<span class="codefrag ">site:</span>" URIs</li>
+<li>Elements with <span class="codefrag">href</span> attributes can be used as identifiers
+          in "<span class="codefrag">site:</span>" URIs</li>
         
 <li>Relative href attribute contents are "accumulated" by prepending hrefs
           from ancestor nodes</li>
         
-<li>Elements without <span class="codefrag ">label</span> attributes (and their children)
+<li>Elements without <span class="codefrag">label</span> attributes (and their children)
           are not displayed in the menu.</li>
         
-<li>Elements below <span class="codefrag ">external-refs</span> are mapped to the
-          "<span class="codefrag ">ext:</span>" scheme.  So "<span class="codefrag ">ext:commons/resolver/</span>" becomes
-          "<span class="codefrag ">http://xml.apache.org/commons/resolver/</span>"</li>
+<li>Elements below <span class="codefrag">external-refs</span> are mapped to the
+          "<span class="codefrag">ext:</span>" scheme.  So "<span class="codefrag">ext:commons/resolver/</span>" becomes
+          "<span class="codefrag">http://xml.apache.org/commons/resolver/</span>"</li>
       
 </ul>
 <p>
@@ -542,11 +542,11 @@
 <h2 class="underlined_10">Generating Menus</h2>
 <div class="section">
 <p>
-        Two files are used to define a site's tabs and menu (<span class="codefrag ">site.xml</span> and
-        <span class="codefrag ">tabs.xml</span>).  Both files are located in
-        <span class="codefrag ">src/documentation/content/xdocs/</span>
+        Two files are used to define a site's tabs and menu (<span class="codefrag">site.xml</span> and
+        <span class="codefrag">tabs.xml</span>).  Both files are located in
+        <span class="codefrag">src/documentation/content/xdocs/</span>
 </p>
-<p>Assume that our <span class="codefrag ">tabs.xml</span> looks like this:</p>
+<p>Assume that our <span class="codefrag">tabs.xml</span> looks like this:</p>
 <pre class="code">
 &lt;tabs ...&gt;
     &lt;tab id="home" label="Home" dir=""/&gt;
@@ -554,48 +554,48 @@
     &lt;tab id="howto" label="How-Tos" dir="community/howto"/&gt;
 &lt;/tabs&gt;
       </pre>
-<p>Using the "<span class="codefrag ">site.xml</span>" listed above, we would get these menus:</p>
+<p>Using the "<span class="codefrag">site.xml</span>" listed above, we would get these menus:</p>
 <p>
         
 <img alt="Menu generated from site.xml" src="images/menu.png">&nbsp;&nbsp;&nbsp;
         <img alt="Community menu generated from site.xml" src="images/menu2.png">&nbsp;&nbsp;&nbsp;
         <img alt="Howto menu generated from site.xml" src="images/menu3.png">
       </p>
-<p>When using the "<span class="codefrag ">dir</span>" attribute as above the value of the
-      "<span class="codefrag ">indexfile</span>" parameter is appended to the value of the 
-      "<span class="codefrag ">dir</span>" attribute (together with a preceding '/'). For example,
+<p>When using the "<span class="codefrag">dir</span>" attribute as above the value of the
+      "<span class="codefrag">indexfile</span>" parameter is appended to the value of the 
+      "<span class="codefrag">dir</span>" attribute (together with a preceding '/'). For example,
       the link for the community tab above is 
-      <span class="codefrag ">community/mailLists.html</span>. Note that "<span class="codefrag ">indexfile</span>"
-      defaults to "<span class="codefrag ">index.html</span>" if no value is supplied. Therefore the
-      link for the howto tab is <span class="codefrag ">community/howto/index.html</span>
+      <span class="codefrag">community/mailLists.html</span>. Note that "<span class="codefrag">indexfile</span>"
+      defaults to "<span class="codefrag">index.html</span>" if no value is supplied. Therefore the
+      link for the howto tab is <span class="codefrag">community/howto/index.html</span>
 </p>
 <a name="N100F0"></a><a name="tabs-external"></a>
 <h3 class="underlined_5">Tabs for External Resources</h3>
 <p>A tab can refer to an external resource by using the 
-        "<span class="codefrag ">href</span>" attribute instead of the "<span class="codefrag ">dir</span>" attribute.
-        The value of "<span class="codefrag ">href</span>" should be the URI of the resource you wish 
+        "<span class="codefrag">href</span>" attribute instead of the "<span class="codefrag">dir</span>" attribute.
+        The value of "<span class="codefrag">href</span>" should be the URI of the resource you wish 
         to link to. For example:</p>
 <pre class="code">
 &lt;tab id="apache" label="XML Apache" href="http://xml.apache.org/"/&gt;
         </pre>
-<p>Unlike the "<span class="codefrag ">dir</span>" attribute, the value of "<span class="codefrag ">href</span>"
+<p>Unlike the "<span class="codefrag">dir</span>" attribute, the value of "<span class="codefrag">href</span>"
         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.</p>
 <a name="N10110"></a><a name="selecting-entries"></a>
 <h3 class="underlined_5">Selecting menu entries</h3>
 <p>Forrest decides which menu entries to display, by examining the
-          "<span class="codefrag ">tab</span>" attributes in the <span class="codefrag ">site.xml</span> file. The children of 
-          all <span class="codefrag ">site.xml</span> entries with a
-          "<span class="codefrag ">tab</span>" which is equal to that of the current page, are
+          "<span class="codefrag">tab</span>" attributes in the <span class="codefrag">site.xml</span> file. The children of 
+          all <span class="codefrag">site.xml</span> entries with a
+          "<span class="codefrag">tab</span>" 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 "<span class="codefrag ">community</span>" element in the 
+          part of the menu (see the "<span class="codefrag">community</span>" element in the 
           example below). Child elements that have a different 
-          "<span class="codefrag ">tab</span>" attribute value will appear in the menu for their
+          "<span class="codefrag">tab</span>" 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 "<span class="codefrag ">howto-samples</span>" element
+          the appropriate name (see the "<span class="codefrag">howto-samples</span>" element
           below).</p>
-<p>Consider our <span class="codefrag ">site.xml</span> example:</p>
+<p>Consider our <span class="codefrag">site.xml</span> example:</p>
 <pre class="code">
 &lt;site label="Forrest" href="" <strong>tab="home"</strong>
   xmlns="http://apache.org/forrest/linkmap/1.0"&gt;
@@ -620,25 +620,25 @@
         &lt;step1 label="Step 1" href="step1.html"/&gt;
       ...</pre>
 <p>
-          Every <span class="codefrag ">site.xml</span> node can potentially have a "<span class="codefrag ">tab</span>" attribute.  If
-          unspecified, nodes inherit the "<span class="codefrag ">tab</span>" of their parent.  Thus
+          Every <span class="codefrag">site.xml</span> node can potentially have a "<span class="codefrag">tab</span>" attribute.  If
+          unspecified, nodes inherit the "<span class="codefrag">tab</span>" of their parent.  Thus
           everything in the <strong>&lt;about&gt;</strong> section has an implicit
-          <span class="codefrag ">tab="home" </span>attribute.</p>
+          <span class="codefrag">tab="home" </span>attribute.</p>
 <div class="note">
 <div class="label">Note</div>
 <div class="content">You can see this by viewing your site's 
         <a href="../abs-menulinks">abs-menulinks</a> pipeline in a
           browser.</div>
 </div>
-<p>Say that the user is viewing the <span class="codefrag ">linking.html</span>
+<p>Say that the user is viewing the <span class="codefrag">linking.html</span>
           page.  The <strong>&lt;linking&gt;</strong> node has an implicit tab
-          value of "<span class="codefrag ">home</span>".  Forrest will select <em>all nodes with
+          value of "<span class="codefrag">home</span>".  Forrest will select <em>all nodes with
             tab="home"</em> and put them in the menu.
         </p>
 <a name="N1016A"></a><a name="other-menu-selection"></a>
 <h3 class="underlined_5">Alternative menu selection mechanisms.</h3>
 <p>
-          The "<span class="codefrag ">tab</span>" attribute-based scheme for selecting a menu's
+          The "<span class="codefrag">tab</span>" 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.
         </p>
@@ -657,11 +657,11 @@
           </p>
 <ul>
             
-<li>Edit <span class="codefrag ">forrest.properties</span> and set
-              <span class="codefrag ">project.menu-scheme=directories</span>
+<li>Edit <span class="codefrag">forrest.properties</span> and set
+              <span class="codefrag">project.menu-scheme=directories</span>
 </li>
             
-<li>Remove the "<span class="codefrag ">id</span>" attributes from <span class="codefrag ">tabs.xml</span>
+<li>Remove the "<span class="codefrag">id</span>" attributes from <span class="codefrag">tabs.xml</span>
               entries.</li>
           
 </ul>
@@ -669,19 +669,19 @@
 <h4>Specifying menus with book.xml</h4>
 <p>
             Historically, menus in Forrest have been generated from a
-            <span class="codefrag ">book.xml</span> file, one per directory.  This mechanism is
-            still available, and if a <span class="codefrag ">book.xml</span> is found, it will be
-            used in preference to the menu generated by the <span class="codefrag ">site.xml</span> file. The <span class="codefrag ">book.xml</span>
-            files can use "<span class="codefrag ">site:</span>" URIs to ease the maintenance burden
+            <span class="codefrag">book.xml</span> file, one per directory.  This mechanism is
+            still available, and if a <span class="codefrag">book.xml</span> is found, it will be
+            used in preference to the menu generated by the <span class="codefrag">site.xml</span> file. The <span class="codefrag">book.xml</span>
+            files can use "<span class="codefrag">site:</span>" URIs to ease the maintenance burden
             that led to obsolescence of book.xml files.  In general, however, we
-            recommend that users avoid <span class="codefrag ">book.xml</span> files.
+            recommend that users avoid <span class="codefrag">book.xml</span> files.
           </p>
 <a name="N101C3"></a><a name="tab-selection"></a>
 <h3 class="underlined_5">Selecting the current tab</h3>
 <p>
           The tab selection algorithm is quite simple: the tab with the
-          "<span class="codefrag ">id</span>" which matches that of the current <span class="codefrag ">site.xml</span>
-          node is "selected". However the interaction of <span class="codefrag ">tabs.xml</span> and <span class="codefrag ">site.xml</span>
+          "<span class="codefrag">id</span>" which matches that of the current <span class="codefrag">site.xml</span>
+          node is "selected". However the interaction of <span class="codefrag">tabs.xml</span> and <span class="codefrag">site.xml</span>
           while powerful, can be complex to establish.
         </p>
 <a name="N101D9"></a><a name="tab-site"></a>
@@ -702,8 +702,8 @@
           
 <li>
             The Forrest website also accompanies your software release
-            in the <span class="codefrag ">site-author</span> directory, so
-            inspect its <span class="codefrag ">tabs.xml</span> and <span class="codefrag ">site.xml</span> to see how it is done. Also see the
+            in the <span class="codefrag">site-author</span> directory, so
+            inspect its <span class="codefrag">tabs.xml</span> and <span class="codefrag">site.xml</span> to see how it is done. Also see the
             'forrest seed site' example. It is not as complex as the Forrest website.
           </li>
           
@@ -713,25 +713,25 @@
           
 <li>
             The value of the tab @id attribute cannot begin with a digit.
-            Likewise, element names in <span class="codefrag ">tabs.xml</span> and <span class="codefrag ">site.xml</span> cannot begin with a digit.
+            Likewise, element names in <span class="codefrag">tabs.xml</span> and <span class="codefrag">site.xml</span> cannot begin with a digit.
           </li>
           
 <li>
-            Add label attributes to <span class="codefrag ">site.xml</span> elements to make the menus show.
-            With nested elements in <span class="codefrag ">site.xml</span> if the outer element does not have a label
+            Add label attributes to <span class="codefrag">site.xml</span> elements to make the menus show.
+            With nested elements in <span class="codefrag">site.xml</span> if the outer element does not have a label
             attribute then the inner elements will not be displayed.
           </li>
           
 <li>
             To cause tabs and menu items to be highlighted, there need to be
-            corresponding elements in <span class="codefrag ">site.xml</span> that have href attributes which match
+            corresponding elements in <span class="codefrag">site.xml</span> that have href attributes which match
             the relevant path.
           </li>
           
 <li>
             When the tab points to a directory, then to make the tab highlighted
             when selected, you need an element which matches index.html within the
-            group of elements that define the menus for this tab in the <span class="codefrag ">site.xml</span>
+            group of elements that define the menus for this tab in the <span class="codefrag">site.xml</span>
             file. That element can be without a label attribute, so that it doesn't
             display as a menu item. However doing that causes that tab's menus
             to be collapsed.
@@ -740,7 +740,7 @@
 <li>
             Q: The tab link in my site assumes that 'index.html'
             is present in the linked-to directory. How do I fix this?
-            A: In <span class="codefrag ">tabs.xml</span> use @href instead of @dir attribute and omit the trailing '/'.
+            A: In <span class="codefrag">tabs.xml</span> use @href instead of @dir attribute and omit the trailing '/'.
             Which file to serve is then a concern of the sitemap.
             See more at the <a href="../docs_0_70/faq.html#tab-index">FAQ</a>.
           </li>
@@ -756,35 +756,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 <span class="codefrag ">src/documentation/skinconf.xml</span> using the 
-      "<span class="codefrag ">toc</span>" element.</p>
+      behaviour in <span class="codefrag">src/documentation/skinconf.xml</span> using the 
+      "<span class="codefrag">toc</span>" element.</p>
 <pre class="code">
 &lt;toc level="2" location="page"/&gt;
       </pre>
 <ul>
         
 <li>
-<strong><span class="codefrag ">level</span></strong> - is the depth to which you
+<strong><span class="codefrag">level</span></strong> - 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.</li>
         
 <li>
-<strong><span class="codefrag ">location</span></strong> - indicates where you
+<strong><span class="codefrag">location</span></strong> - indicates where you
         want the table of contents to be rendered. It can be set to one of
         three values:
           <ul>
             
 <li>
-<span class="codefrag ">page</span> - the table of contents will be rendered
+<span class="codefrag">page</span> - the table of contents will be rendered
             at the top of the body of your page</li>
             
 <li>
-<span class="codefrag ">menu</span> - the table of contents will be rendered
+<span class="codefrag">menu</span> - the table of contents will be rendered
             in the menu to the left of the body of the page</li>
             
 <li>
-<span class="codefrag ">menu, page</span> - table of contents will be rendered
+<span class="codefrag">menu, page</span> - table of contents will be rendered
             in both the page and the menu positions</li>
           
 </ul>
@@ -802,8 +802,8 @@
 <h3 class="underlined_5">Direct linking</h3>
 <p>
           In earlier versions of Forrest (and in similar systems), there has
-          been only one URI space: that of the generated site.  If <span class="codefrag ">index.xml</span> wants to
-          link to <span class="codefrag ">todo.xml</span> then <span class="codefrag ">index.xml</span> would use
+          been only one URI space: that of the generated site.  If <span class="codefrag">index.xml</span> wants to
+          link to <span class="codefrag">todo.xml</span> then <span class="codefrag">index.xml</span> would use
         </p>
 <pre class="code">
           &lt;a href="todo.html"&gt;to-do list&lt;a&gt;
@@ -834,8 +834,8 @@
           
 <dt>todo</dt>
           
-<dd>identifies the content in <span class="codefrag ">todo.xml</span> by reference to a
-            "node" of content declared in <span class="codefrag ">site.xml</span>
+<dd>identifies the content in <span class="codefrag">todo.xml</span> by reference to a
+            "node" of content declared in <span class="codefrag">site.xml</span>
 </dd>
         
 </dl>
@@ -848,13 +848,13 @@
 <a name="N102AC"></a><a name="resolve-site-uris"></a>
 <h4>Resolving site: URIs</h4>
 <p>
-            So how does "<span class="codefrag ">site:v0.70//todo</span>" get resolved?  A full answer
+            So how does "<span class="codefrag">site:v0.70//todo</span>" get resolved?  A full answer
             is provided in the <a href="#implementation">implementation</a>
-            section.  Essentially, the "<span class="codefrag ">todo</span>" part has
-            "<span class="codefrag ">/site//</span>" prepended, and "<span class="codefrag ">/@href</span>" appended, to
-            form the string "<span class="codefrag ">/site//todo/@href</span>".  This is
-            then used as an XPath expression in <span class="codefrag ">site.xml</span> to identify the string
-            replacement, in this case "<span class="codefrag ">todo.html</span>"
+            section.  Essentially, the "<span class="codefrag">todo</span>" part has
+            "<span class="codefrag">/site//</span>" prepended, and "<span class="codefrag">/@href</span>" appended, to
+            form the string "<span class="codefrag">/site//todo/@href</span>".  This is
+            then used as an XPath expression in <span class="codefrag">site.xml</span> to identify the string
+            replacement, in this case "<span class="codefrag">todo.html</span>"
           </p>
 <p>
             Thus by modifying the XPath prefix and suffix, almost any XML
@@ -864,33 +864,33 @@
 <div class="label">Note</div>
 <div class="content">
             Actually, the XPath is applied to XML generated dynamically from
-            <span class="codefrag ">site.xml</span>.  The generated XML has each "@href" fully expanded ("absolutized")
+            <span class="codefrag">site.xml</span>.  The generated XML has each "@href" fully expanded ("absolutized")
             and dot-dots (..) added as needed ("relativized").
           </div>
 </div>
 <p>
             Notice that the "//" allows us any degree of specificity when linking.
-            In the sample <span class="codefrag ">site.xml</span> above, both "<span class="codefrag ">site:v0.70//new_content_type</span>" and
-            "<span class="codefrag ">site:about/your-project/new_content_type</span>" identify the
+            In the sample <span class="codefrag">site.xml</span> above, both "<span class="codefrag">site:v0.70//new_content_type</span>" and
+            "<span class="codefrag">site:about/your-project/new_content_type</span>" identify the
             same node.  It is up to you to decide how specific to make links.  One
-            nice benefit of link "ambiguity" is that <span class="codefrag ">site.xml</span> can be reorganized
+            nice benefit of link "ambiguity" is that <span class="codefrag">site.xml</span> can be reorganized
             without breaking links.  For example, "new_content_type" currently
             identifies a node in "your-project".  By leaving that fact unspecified
-            in "<span class="codefrag ">site:new_content_type</span>" we are free to make
+            in "<span class="codefrag">site:new_content_type</span>" we are free to make
             "new_content_type" its own XML file, or a node in another file, in
             another category.
           </p>
 <a name="N102EA"></a><a name="resolve-ext-uris"></a>
 <h4>ext: URIs: linking to external URLs</h4>
 <p>
-            The "<span class="codefrag ">ext:</span>" scheme was created partly to demonstrate the
+            The "<span class="codefrag">ext:</span>" scheme was created partly to demonstrate the
             ease with which new schemes can be defined, and partly for practical
-            use. The "<span class="codefrag ">ext:</span>" URIs identify nodes in <span class="codefrag ">site.xml</span> below the
+            use. The "<span class="codefrag">ext:</span>" URIs identify nodes in <span class="codefrag">site.xml</span> below the
             &lt;external-refs&gt; node.  By convention, nodes here link to URLs
             outside the website, and are not listed in the menu generated from
-            the <span class="codefrag ">site.xml</span> file.
+            the <span class="codefrag">site.xml</span> file.
           </p>
-<p>Here is a <span class="codefrag ">site.xml</span> snippet illustrating "<span class="codefrag ">external-refs</span>":</p>
+<p>Here is a <span class="codefrag">site.xml</span> snippet illustrating "<span class="codefrag">external-refs</span>":</p>
 <pre class="code">
 &lt;site&gt;
   ...
@@ -911,30 +911,30 @@
           
 </p>
 <p>
-            The general rules of <span class="codefrag ">site.xml</span> and "<span class="codefrag ">site:</span>" linking apply.
+            The general rules of <span class="codefrag">site.xml</span> and "<span class="codefrag">site:</span>" linking apply.
             Specifically, the "@href" aggregation makes defining large numbers of
             related URLs easy.
           </p>
 <a name="N1031D"></a><a name="source-uris"></a>
 <h4>Theory: source URIs</h4>
 <p>
-            The "<span class="codefrag ">site:</span>" URIs like "<span class="codefrag ">site:v0.70//todo</span>" are examples of
+            The "<span class="codefrag">site:</span>" URIs like "<span class="codefrag">site:v0.70//todo</span>" are examples of
             "<em>source</em>" URIs, in contrast to the more usual
-            <span class="codefrag ">foo.html</span> style URIs, which we here call
+            <span class="codefrag">foo.html</span> style URIs, which we here call
             "<em>destination</em>" URIs.  This introduces an important concept: that
             the "<em>source</em>" 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 "<span class="codefrag ">http:</span>" or relative URIs
+            all be translated into plain old "<span class="codefrag">http:</span>" or relative URIs
             in the destination URI space, just like exotic XML source formats are
             translated into plain old HTML in the output.
           </p>
 <a name="N1033C"></a><a name="future-schemes"></a>
 <h4>Future schemes</h4>
 <p>
-            So far, the "<span class="codefrag ">site:</span>" and "<span class="codefrag ">ext:</span>" schemes are defined.
+            So far, the "<span class="codefrag">site:</span>" and "<span class="codefrag">ext:</span>" 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.
           </p>
@@ -948,10 +948,10 @@
               
 <td colspan="1" rowspan="1">java</td>
               <td colspan="1" rowspan="1">java:org.apache.proj.SomeClass</td>
-              <td colspan="1" rowspan="1"><span class="codefrag ">../../apidocs/org/apache/proj/SomeClass.html</span></td>
+              <td colspan="1" rowspan="1"><span class="codefrag">../../apidocs/org/apache/proj/SomeClass.html</span></td>
               <td colspan="1" rowspan="1">
                 Links to documentation for a Java class (typically generated by
-                <span class="codefrag ">javadoc</span>).
+                <span class="codefrag">javadoc</span>).
               </td>
             
 </tr>
@@ -960,9 +960,9 @@
               
 <td colspan="1" rowspan="1">mail</td>
               <td colspan="1" rowspan="1">mail::&lt;Message-Id&gt;</td>
-              <td colspan="1" rowspan="1"><span class="codefrag ">http://marc.theaimsgroup.com?t=12345678</span></td>
+              <td colspan="1" rowspan="1"><span class="codefrag">http://marc.theaimsgroup.com?t=12345678</span></td>
               <td colspan="1" rowspan="1">
-                Links to an email, identified by its <span class="codefrag ">Message-Id</span>
+                Links to an email, identified by its <span class="codefrag">Message-Id</span>
                 header. Any mail archive website could be used.
               </td>
             
@@ -972,7 +972,7 @@
               
 <td colspan="1" rowspan="1">search</td>
               <td colspan="1" rowspan="1">search:&lt;searchterm&gt;</td>
-              <td colspan="1" rowspan="1"><span class="codefrag ">http://www.google.com/search?q=searchterm</span></td>
+              <td colspan="1" rowspan="1"><span class="codefrag">http://www.google.com/search?q=searchterm</span></td>
               <td colspan="1" rowspan="1">Link to set of results from a search engine</td>
             
 </tr>
@@ -981,10 +981,10 @@
               
 <td colspan="1" rowspan="1">person</td>
               <td colspan="1" rowspan="1">person:JT, person:JT/blog etc</td>
-              <td colspan="1" rowspan="1"><span class="codefrag ">mailto:jefft&lt;at&gt;apache.org</span>,
-                <span class="codefrag ">http://www.webweavertech.com/jefft/weblog/</span></td>
+              <td colspan="1" rowspan="1"><span class="codefrag">mailto:jefft&lt;at&gt;apache.org</span>,
+                <span class="codefrag">http://www.webweavertech.com/jefft/weblog/</span></td>
               <td colspan="1" rowspan="1">
-                A "<span class="codefrag ">person:</span>" scheme could be used, say, to insert an
+                A "<span class="codefrag">person:</span>" scheme could be used, say, to insert an
                 automatically obfuscated email address, or link to a URI in some
                 way associated with that person.
               </td>
@@ -994,10 +994,10 @@
 </table>
 <p>
             There are even more possibilities in specific environments.  In an
-            intranet, a "<span class="codefrag ">project:XYZ</span>" scheme could identify company
+            intranet, a "<span class="codefrag">project:XYZ</span>" scheme could identify company
             project pages.  In a project like <a href="http://ant.apache.org/">Apache
               Ant</a>, each Task could be identified with
-            <span class="codefrag ">task:&lt;taskname&gt;</span>, e.g. <span class="codefrag ">task:pathconvert</span>.
+            <span class="codefrag">task:&lt;taskname&gt;</span>, e.g. <span class="codefrag">task:pathconvert</span>.
           </p>
 </div>
     
@@ -1005,13 +1005,13 @@
 <h2 class="underlined_10">Concept</h2>
 <div class="section">
 <p>
-        The "<span class="codefrag ">site:</span>" scheme and associated ideas for <span class="codefrag ">site.xml</span> were
+        The "<span class="codefrag">site:</span>" scheme and associated ideas for <span class="codefrag">site.xml</span> were
         originally described in <a href="http://marc.theaimsgroup.com/?l=forrest-dev&m=103444028129281&w=2">the 'linkmap' RT
           email</a> 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 <span class="codefrag ">site.xml</span> (section 4).  However, what is currently implemented
+        creation of <span class="codefrag">site.xml</span> (section 4).  However, what is currently implemented
         gains most of the advantages of the system.
       </p>
 </div>

Modified: forrest/site/docs_0_70/primer.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_70/primer.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_70/primer.html (original)
+++ forrest/site/docs_0_70/primer.html Sun Dec 18 17:31:25 2005
@@ -429,9 +429,9 @@
 <div class="label">Note</div>
 <div class="content">This process is not quite ready for prime time yet, but it gives
         you an idea where we are heading to. Website generation with skins currently
-        works, try using the <span class="codefrag ">docs</span> target when invoking the
-        <span class="codefrag ">build</span> script. Add a <span class="codefrag ">project.skin</span> property when invoking
-        the build script to experience Forrest skins: <span class="codefrag ">build{.bat|.sh}
+        works, try using the <span class="codefrag">docs</span> target when invoking the
+        <span class="codefrag">build</span> script. Add a <span class="codefrag">project.skin</span> property when invoking
+        the build script to experience Forrest skins: <span class="codefrag">build{.bat|.sh}
           -Dproject.skin=&lt;thenameoftheskintouse&gt; docs</span>. Read our
         <a href="#cvs">CVS crash course</a> to get hold of the current codebase and
         start playing with it.</div>
@@ -561,7 +561,7 @@
 <li>Click on Admin-&gt;Preferences;</li> 
           
 <li> In "Enter the CVSROOT:" enter
-            "<span class="codefrag ">:pserver:anoncvs@cvs.apache.org:/home/cvspublic</span>" (without
+            "<span class="codefrag">:pserver:anoncvs@cvs.apache.org:/home/cvspublic</span>" (without
             quotes);</li> 
           
 <li>In "Authentication:" choose "passwd file on the cvs server";</li> 
@@ -570,12 +570,12 @@
           
 <li>Click Admin-&gt;Login;</li> 
           
-<li> When asked for the password: answer "<span class="codefrag ">anoncvs</span>"
+<li> When asked for the password: answer "<span class="codefrag">anoncvs</span>"
             (without quotes);</li> 
           
 <li> Click "Create-&gt;Checkout module";</li> 
           
-<li>Module name and path on the server is "<span class="codefrag ">xml-forrest</span>"
+<li>Module name and path on the server is "<span class="codefrag">xml-forrest</span>"
             (no quotes);</li> 
           
 <li>Choose a dir to put the source code in;</li> 
@@ -585,7 +585,7 @@
 <li>If everything goes well, messages will start to appear in the log
             window;</li> 
           
-<li>Wait until you see "<span class="codefrag ">*****CVS exited normally with code
+<li>Wait until you see "<span class="codefrag">*****CVS exited normally with code
               0*****</span>" in the log window;</li> 
           
 <li>The Forrest source is now on your harddrive.</li> 
@@ -600,15 +600,15 @@
           
 <li>Start the shell of your choice.</li> 
           
-<li>Enter "<span class="codefrag ">cvs -d
+<li>Enter "<span class="codefrag">cvs -d
               :pserver:anoncvs@cvs.apache.org:/home/cvspublic login</span>".</li> 
           
-<li>When asked for the password: answer "<span class="codefrag ">anoncvs</span>".</li> 
+<li>When asked for the password: answer "<span class="codefrag">anoncvs</span>".</li> 
           
-<li>Enter "<span class="codefrag ">cvs -d
+<li>Enter "<span class="codefrag">cvs -d
               :pserver:anoncvs@cvs.apache.org:/home/cvspublic -z3 checkout
               xml-forrest</span>". This will create a directory called
-            "<span class="codefrag ">xml-forrest</span>" where the Forrest source will be stored.</li> 
+            "<span class="codefrag">xml-forrest</span>" where the Forrest source will be stored.</li> 
           
 <li>Wait until cvs has finished.</li> 
           
@@ -616,15 +616,15 @@
         
 </ol>
 <p>In case you want to update your Forrest source tree to the current
-          version, change to the "<span class="codefrag ">xml-forrest</span>" directory and invoke
-          "<span class="codefrag ">cvs -z3 update -d -P</span>".</p>
+          version, change to the "<span class="codefrag">xml-forrest</span>" directory and invoke
+          "<span class="codefrag">cvs -z3 update -d -P</span>".</p>
 </div> 
     
 <a name="N1017F"></a><a name="Forrest+distribution"></a>
 <h2 class="underlined_10">Forrest distribution</h2>
 <div class="section">
 <p>Once you retrieved Forrest from its CVS repository, you will end up
-        with a filesystem hierarchy similar to this inside the <span class="codefrag ">xml-forrest</span>
+        with a filesystem hierarchy similar to this inside the <span class="codefrag">xml-forrest</span>
         home directory:</p>
 <div class="warning">
 <div class="label">Warning</div>
@@ -673,34 +673,34 @@
     +---ant                         Ant 1.6-dev scripts and jars
 +---stylesheets                     Stylesheets used for project root XML files
 </pre>
-<p>The <span class="codefrag ">xml-forrest</span> home directory consists of the main Ant
-        build script (<span class="codefrag ">build.xml</span>) and platform-specific batch files/shell
+<p>The <span class="codefrag">xml-forrest</span> home directory consists of the main Ant
+        build script (<span class="codefrag">build.xml</span>) and platform-specific batch files/shell
         scripts to invoke it. Forrest comes with Ant included, so you do not need to
         install Ant separately.</p>
 <p>Running Forrest is a batch operation you can start using the provided
-        <span class="codefrag ">build.{sh|bat} &lt;targetname&gt;</span>. The current main targets
+        <span class="codefrag">build.{sh|bat} &lt;targetname&gt;</span>. The current main targets
         are:</p>
 <ul> 
         
 <li>
-<strong><span class="codefrag ">docs</span></strong> - generates an HTML rendition of
-          the Forrest website using the default <span class="codefrag ">forrest-site</span> skin</li> 
+<strong><span class="codefrag">docs</span></strong> - generates an HTML rendition of
+          the Forrest website using the default <span class="codefrag">forrest-site</span> skin</li> 
         
 <li>
-<strong><span class="codefrag ">clean</span></strong> - cleans out the
-          <span class="codefrag ">build</span> directory</li> 
+<strong><span class="codefrag">clean</span></strong> - cleans out the
+          <span class="codefrag">build</span> directory</li> 
         
 <li>
-<strong><span class="codefrag ">webapp</span></strong> - for those who cannot resist
+<strong><span class="codefrag">webapp</span></strong> - for those who cannot resist
           running Forrest live instead of its commandline invocation, this target builds
           a WAR file you can deploy in your servlet container (currently only tested for
           Tomcat 4.0.1). Mount-point of the web application will be
-          <span class="codefrag ">xml-forrest</span>.</li> 
+          <span class="codefrag">xml-forrest</span>.</li> 
       
 </ul>
-<p>After a build run, Forrest creates a <span class="codefrag ">build</span> directory. You
-        can find the generated website in the <span class="codefrag ">build/xml-forrest/docs/</span>
-        directory. Forrest also creates a <span class="codefrag ">tools/tmp/anttasks/</span> upon its
+<p>After a build run, Forrest creates a <span class="codefrag">build</span> directory. You
+        can find the generated website in the <span class="codefrag">build/xml-forrest/docs/</span>
+        directory. Forrest also creates a <span class="codefrag">tools/tmp/anttasks/</span> upon its
         first invocation. These are Centipede-specific compiled Ant tasks.</p>
 </div> 
     
@@ -715,30 +715,30 @@
         mechanism, extensive use of external parameter entities and an entity resolver
         capable of resolving entities through the aforementioned catalog mechanism. For
         the docheads amongst us, this means we adhere to the strict use of
-        <span class="codefrag ">PUBLIC</span> entity identifiers both in document instances and DTD
+        <span class="codefrag">PUBLIC</span> entity identifiers both in document instances and DTD
         modules.</p>
 <p>We have currently identified the following document types:</p>
 <ul> 
         
-<li>General documents (<span class="codefrag ">document-v11.dtd</span>),</li> 
+<li>General documents (<span class="codefrag">document-v11.dtd</span>),</li> 
         
-<li>How-Tos (<span class="codefrag ">howto-v10.dtd</span>),</li> 
+<li>How-Tos (<span class="codefrag">howto-v10.dtd</span>),</li> 
         
-<li>Collections of FAQs (<span class="codefrag ">faq-v11.dtd)</span>.</li> 
+<li>Collections of FAQs (<span class="codefrag">faq-v11.dtd)</span>.</li> 
       
 </ul>
 <p>Some work is also under its way for other document types, in close
         collaboration with the Cocoon project. You will also find some older document
-        types such as <span class="codefrag ">changes</span>, <span class="codefrag ">javadoc</span>,
-        <span class="codefrag ">specification</span> and <span class="codefrag ">todo</span>, which are currently under
+        types such as <span class="codefrag">changes</span>, <span class="codefrag">javadoc</span>,
+        <span class="codefrag">specification</span> and <span class="codefrag">todo</span>, which are currently under
         consideration for automatic generation and maintenance using Gump or Centipede
         descriptors and the like. DTDs will be subject of serious version management as
         soon as Forrest has a 1.0 release: they are made to depend upon.</p>
-<p>The DTDs are located in <span class="codefrag ">src/resources/schema/dtd</span> and also
+<p>The DTDs are located in <span class="codefrag">src/resources/schema/dtd</span> and also
         refer to some character entity collections stored in the
-        <span class="codefrag ">src/resources/schema/entity</span> directory. These are referred to by
-        the declarations found in the <span class="codefrag ">src/resources/schema/catalog</span> OASIS
-        Catalog file. Take special care using the correct <span class="codefrag ">PUBLIC</span>
+        <span class="codefrag">src/resources/schema/entity</span> directory. These are referred to by
+        the declarations found in the <span class="codefrag">src/resources/schema/catalog</span> OASIS
+        Catalog file. Take special care using the correct <span class="codefrag">PUBLIC</span>
         identifiers in the DTD declaration of your instances:</p>
 <pre class="code">&lt;?xml version="1.0"?&gt;
 &lt;!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "http://apache.org/forrest/dtd/document-v12.dtd"&gt;
@@ -747,7 +747,7 @@
   </pre>
 <p>The exact local location of the DTD for validation purposes is
         obtained by the entity resolver evaluating the mapping scheme as defined in the
-        <span class="codefrag ">catalog</span> file. This makes sure that you can move and re-arrange
+        <span class="codefrag">catalog</span> file. This makes sure that you can move and re-arrange
         your document instances apart from your DTD files. Later on, the DTDs will be
         web-accessible from the Forrest website for your perusal.</p>
 </div> 
@@ -755,7 +755,7 @@
 <a name="N1021D"></a><a name="sitemap"></a>
 <h2 class="underlined_10">Forrest site generation using Cocoon</h2>
 <div class="section">
-<p>The <span class="codefrag ">docs</span> target of the Forrest build environment invokes
+<p>The <span class="codefrag">docs</span> target of the Forrest build environment invokes
         Cocoon as a command-line application to generate an HTML rendition of the
         project's documentation. It is not within the scope of this document to explain
         the Cocoon internals, please read its own
@@ -773,7 +773,7 @@
         transformed by a different XSLT stylesheet, aggregated by Cocoon with a
         post-aggregation stylesheet adding the overall page grid and look &amp; feel.
         This simple example is handled by the following <em>sitemap</em> snippets
-        (<span class="codefrag ">src/documentation/conf/sitemap.xmap</span>):</p>
+        (<span class="codefrag">src/documentation/conf/sitemap.xmap</span>):</p>
 <pre class="code">&lt;map:match pattern="*.html"&gt;
   &lt;map:aggregate element="site"&gt;
     &lt;map:part src="cocoon:/book-{1}.xml"/&gt;
@@ -802,63 +802,63 @@
   &lt;map:serialize/&gt;
 &lt;/map:resource&gt;</pre>
 <p>When an URL (e.g.
-        <span class="codefrag ">http://forrest.apache.org/index.html</span>) is passed through the
+        <span class="codefrag">http://forrest.apache.org/index.html</span>) is passed through the
         Cocoon system to generate the required page, the pipeline flow is basically as
         follows:</p>
 <ol> 
         
-<li>The URL is matched by the <span class="codefrag ">*.html</span> pattern</li> 
+<li>The URL is matched by the <span class="codefrag">*.html</span> pattern</li> 
         
 <li>Cocoon responds by aggregating two 'sub-requests'. The first is for
-          the resource <span class="codefrag ">book-{1}.xml</span>, the second is for the resource
-          <span class="codefrag ">body-{1}.xml</span>. The <span class="codefrag ">{1}</span> parameter is replaced by the
+          the resource <span class="codefrag">book-{1}.xml</span>, the second is for the resource
+          <span class="codefrag">body-{1}.xml</span>. The <span class="codefrag">{1}</span> parameter is replaced by the
           values of the first wildcard in the matching pattern above. These
           'sub-requests' are passed through the Cocoon pipeline just like any other
           request. This results in the following flow:</li> 
         
 <ol> 
           
-<li>The first 'sub-request' (for <span class="codefrag ">book-index.xml</span> is matched
-            by the <span class="codefrag ">**book-**.xml</span> pattern. This results in the file
-            <span class="codefrag ">content/xdocs/book.xml</span> being read. This document is then run
-            through the <span class="codefrag ">book2menu</span> stylesheet (which produces an HTML fragment
+<li>The first 'sub-request' (for <span class="codefrag">book-index.xml</span> is matched
+            by the <span class="codefrag">**book-**.xml</span> pattern. This results in the file
+            <span class="codefrag">content/xdocs/book.xml</span> being read. This document is then run
+            through the <span class="codefrag">book2menu</span> stylesheet (which produces an HTML fragment
             comprising the site navigation, the red area in the image above.</li> 
           
-<li>The second 'sub-request' is matched by the <span class="codefrag ">body-**.xml</span>
-            pattern. This results in the file <span class="codefrag ">index.xml</span> being transformed
-            using the <span class="codefrag ">document2html</span> stylesheet, the yellow area in the
+<li>The second 'sub-request' is matched by the <span class="codefrag">body-**.xml</span>
+            pattern. This results in the file <span class="codefrag">index.xml</span> being transformed
+            using the <span class="codefrag">document2html</span> stylesheet, the yellow area in the
             screenshot.</li> 
         
 </ol> 
         
 <li>The aggregation result is then transformed using the
-          <span class="codefrag ">site2xhtml</span> stylesheet which adds the cherries to the cake. The
+          <span class="codefrag">site2xhtml</span> stylesheet which adds the cherries to the cake. The
           grey zone.</li> 
       
 </ol>
 <p>These <em>skin-specific</em> stylesheets are located in
-        <span class="codefrag ">src/documentation/skins/&lt;nameoftheskin&gt;/xslt/html</span>, so if you
+        <span class="codefrag">src/documentation/skins/&lt;nameoftheskin&gt;/xslt/html</span>, so if you
         want to add your own skin, this is the place to be. Apart from these, there
         exist a number of other stylesheets located in
-        <span class="codefrag ">src/documentation/library/xslt</span> and more importantly:</p>
+        <span class="codefrag">src/documentation/library/xslt</span> and more importantly:</p>
 <ul> 
         
 <li>
-<span class="codefrag ">faq2document</span>: transforms documents following the
-          <span class="codefrag ">faq-v11</span> DTD to <span class="codefrag ">document-v11</span> grammar</li> 
+<span class="codefrag">faq2document</span>: transforms documents following the
+          <span class="codefrag">faq-v11</span> DTD to <span class="codefrag">document-v11</span> grammar</li> 
         
 <li>
-<span class="codefrag ">howto2document</span>: transforms documents following the
-          <span class="codefrag ">howto-v10</span> DTD to <span class="codefrag ">document-v11</span> grammar</li> 
+<span class="codefrag">howto2document</span>: transforms documents following the
+          <span class="codefrag">howto-v10</span> DTD to <span class="codefrag">document-v11</span> grammar</li> 
         
 <li>and some others.</li> 
       
 </ul>
 <p>As you see, all documents, regardless of their original DTD, are
-        transformed to the <span class="codefrag ">document</span> DTD prior to rendition. This
+        transformed to the <span class="codefrag">document</span> DTD prior to rendition. This
         alleviates the burden of adding new skins to implementing 3 simple stylesheets:
-        <span class="codefrag ">book2menu</span>, <span class="codefrag ">document2html</span> and
-        <span class="codefrag ">site2xhtml</span>.</p>
+        <span class="codefrag">book2menu</span>, <span class="codefrag">document2html</span> and
+        <span class="codefrag">site2xhtml</span>.</p>
 </div> 
     
 <a name="N102CC"></a><a name="Where+we+are+heading+to"></a>
@@ -901,7 +901,7 @@
           
 <th colspan="1" rowspan="1">Skins</th> 
           <td colspan="1" rowspan="1">We currently have a nice set of skins which should be solidified.
-            Furthermore, we need some serious finetuning of the <span class="codefrag ">forrest-site</span>
+            Furthermore, we need some serious finetuning of the <span class="codefrag">forrest-site</span>
             skin that will become the new xml.apache.org look&amp;feel.</td> 
         
 </tr> 
@@ -922,7 +922,7 @@
           
 <th colspan="1" rowspan="1">Build Management</th> 
           <td colspan="1" rowspan="1">Fool-proof automation of Forrest runs and site publication using
-            secure transfer methods and <span class="codefrag ">cron</span> jobs.</td> 
+            secure transfer methods and <span class="codefrag">cron</span> jobs.</td> 
         
 </tr> 
         

Modified: forrest/site/docs_0_70/project-sitemap.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_70/project-sitemap.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_70/project-sitemap.html (original)
+++ forrest/site/docs_0_70/project-sitemap.html Sun Dec 18 17:31:25 2005
@@ -357,7 +357,7 @@
 <a name="N10029"></a><a name="how"></a>
 <h2 class="underlined_10">How does it work?</h2>
 <div class="section">
-<p>If a project has a <span class="codefrag ">sitemap.xmap</span> file in it's 
+<p>If a project has a <span class="codefrag">sitemap.xmap</span> 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_70/searching.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_70/searching.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_70/searching.html (original)
+++ forrest/site/docs_0_70/searching.html Sun Dec 18 17:31:25 2005
@@ -351,15 +351,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 <span class="codefrag ">forrest site</span>).</p>
+	with <span class="codefrag">forrest site</span>).</p>
 <p>To use Google SiteSearch in your Forrest application, open
-	your <span class="codefrag ">skinconf.xml</span> file. By default this file is
-	in the <span class="codefrag ">src/documentation</span> subdirectory of your
-	Forrest repository root. Find the <span class="codefrag ">&lt;search&gt;</span>
+	your <span class="codefrag">skinconf.xml</span> file. By default this file is
+	in the <span class="codefrag">src/documentation</span> subdirectory of your
+	Forrest repository root. Find the <span class="codefrag">&lt;search&gt;</span>
 	element; it should be near the top of the file. If the element
 	does not exist, create it below the
-	<span class="codefrag ">&lt;skinconfig&gt;</span> opening tag. If there is any
-	attribute named <span class="codefrag ">provider</span>, remove it. The element
+	<span class="codefrag">&lt;skinconfig&gt;</span> opening tag. If there is any
+	attribute named <span class="codefrag">provider</span>, remove it. The element
 	should look similar to this:</p>
 <pre class="code">&lt;search name="MyProject"
 	domain="myproject.com"/&gt;</pre>
@@ -384,26 +384,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 '<span class="codefrag ">forrest
+	will not work in a static site generated with the '<span class="codefrag">forrest
 	  site</span>' command.</p>
 <p>In order to enable Lucene-based full-text search in your
 	Forrest application, you must first edit your
-	<span class="codefrag ">skinconf.xml</span> file. Locate the
-	<span class="codefrag ">&lt;search&gt;</span> element. If the element does not
+	<span class="codefrag">skinconf.xml</span> file. Locate the
+	<span class="codefrag">&lt;search&gt;</span> element. If the element does not
 	exist, insert it right underneath the
-	<span class="codefrag ">&lt;skinconfig&gt;</span> opening tag. Add an attribute
-	named <span class="codefrag ">provider</span> with a value of
-	<span class="codefrag ">lucene</span>, so that the element looks similar to
+	<span class="codefrag">&lt;skinconfig&gt;</span> opening tag. Add an attribute
+	named <span class="codefrag">provider</span> with a value of
+	<span class="codefrag">lucene</span>, so that the element looks similar to
 	this:</p>
 <pre class="code">&lt;search name="MyProject" domain="myproject.com"
 	provider="lucene"/&gt;</pre>
 <p>Next, create and run your Forrest webapp. This may mean
-	simply invoking <span class="codefrag ">forrest run</span>, or building and
-	bundling a servlet webapp (with <span class="codefrag ">forrest webapp</span>),
+	simply invoking <span class="codefrag">forrest run</span>, or building and
+	bundling a servlet webapp (with <span class="codefrag">forrest webapp</span>),
 	and then deploying it to your servlet container.</p>
 <p>You can now build a Lucene search index by pointing your web
 	browser at
-	<span class="codefrag ">http://localhost:8888/lucene-update.html</span>. This
+	<span class="codefrag">http://localhost:8888/lucene-update.html</span>. This
 	generates the search index and provides some information about
 	the index generation process.</p>
 <div class="note">
@@ -411,7 +411,7 @@
 <div class="content">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
-	<span class="codefrag ">forrest run</span>.</div>
+	<span class="codefrag">forrest run</span>.</div>
 </div>
 <p>Now you can utilize the full-text search box, located in the
 	top-right corner of the rendered Forrest pages. Search results
@@ -438,8 +438,8 @@
 	usable servlet-capable web server at your disposal (meaning
 	you can't use Lucene, either).</p>
 <p>To disable full-text search completely, open the
-	<span class="codefrag ">skinconf.xml</span> file and remove (or comment out) the
-	entire <span class="codefrag ">&lt;search&gt;</span> element.</p>
+	<span class="codefrag">skinconf.xml</span> file and remove (or comment out) the
+	entire <span class="codefrag">&lt;search&gt;</span> element.</p>
 </div>
   
 </div>

Modified: forrest/site/docs_0_70/sitemap-ref.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_70/sitemap-ref.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_70/sitemap-ref.html (original)
+++ forrest/site/docs_0_70/sitemap-ref.html Sun Dec 18 17:31:25 2005
@@ -425,18 +425,18 @@
       </p>
 <p>
         You can add pre-processing sitemaps to your project
-        <span class="codefrag ">src/documentation</span> directory (or wherever
-        <span class="codefrag ">${project.sitemap-dir}</span> points to). Any match that
+        <span class="codefrag">src/documentation</span> directory (or wherever
+        <span class="codefrag">${project.sitemap-dir}</span> 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 
         "<a href="../docs_0_70/project-sitemap.html">Using project sitemaps</a>".
       </p>
 <p>
-        Another way to experiment with the sitemap is to do '<span class="codefrag ">forrest
+        Another way to experiment with the sitemap is to do '<span class="codefrag">forrest
         run</span>' on a Forrest-using site.  Changes to the core
-        <span class="codefrag ">*.xmap</span> files will now be immediately visible
-        at <span class="codefrag ">&gt;http://localhost:8888/</span>
+        <span class="codefrag">*.xmap</span> files will now be immediately visible
+        at <span class="codefrag">&gt;http://localhost:8888/</span>
       
 </p>
 </div>
@@ -501,7 +501,7 @@
 <tr>
           
 <th colspan="1" rowspan="1">raw.xmap</th>
-          <td colspan="1" rowspan="1">Serves files located in <span class="codefrag ">src/documentation/content/xdocs</span>
+          <td colspan="1" rowspan="1">Serves files located in <span class="codefrag">src/documentation/content/xdocs</span>
             that are not to be modified by Forrest.</td>
         
 </tr>
@@ -526,7 +526,7 @@
 <th colspan="1" rowspan="1">status.xmap</th>
           <td colspan="1" rowspan="1">Generates <a href="../docs_0_70/changes.html">changes</a> and 
           <a href="../docs_0_70/todo.html">todo</a> pages from a single
-            <span class="codefrag ">status.xml</span> in the project root.
+            <span class="codefrag">status.xml</span> in the project root.
           </td>
         
 </tr>
@@ -598,14 +598,14 @@
         format.
       </p>
 <p>
-        Source pipelines always have a "<span class="codefrag ">.xml</span>" extension.
+        Source pipelines always have a "<span class="codefrag">.xml</span>" extension.
         Thus, 
         <a href="index.xml">index.xml</a> gives you the XML source for the
         index page.  Likewise, <a href="faq.xml">faq.xml</a> gives you XML
         for the FAQ (transformed from FAQ syntax), and 
         <a href="changes.xml">changes.xml</a> returns XML from the status.xml file.
-        Take any page, and replace its extension (<span class="codefrag ">.html</span> or
-        <span class="codefrag ">.pdf</span>) with <span class="codefrag ">.xml</span> and you'll have the Source
+        Take any page, and replace its extension (<span class="codefrag">.html</span> or
+        <span class="codefrag">.pdf</span>) with <span class="codefrag">.xml</span> and you'll have the Source
         XML.
       </p>
 <p>
@@ -630,8 +630,8 @@
 <h3 class="underlined_5">forrest.xmap</h3>
 <p>
           Most of the usual Source pipelines are defined in
-          <span class="codefrag ">forrest.xmap</span> which is the default (fallback) handler for
-          <span class="codefrag ">**.xml</span> pages. The forrest.xmap uses the 
+          <span class="codefrag">forrest.xmap</span> which is the default (fallback) handler for
+          <span class="codefrag">**.xml</span> pages. The forrest.xmap uses the 
           <a href="../docs_0_70/cap.html">SourceTypeAction</a> to determine the type of XML
           it is processing, and converts it to document-v13 if necessary.
         </p>
@@ -651,8 +651,8 @@
 <a name="N10175"></a><a name="other_source"></a>
 <h3 class="underlined_5">Other source pipelines</h3>
 <p>As mentioned above, all non-core Source pipelines are distributed in
-          independent <span class="codefrag ">*.xmap</span> files.  There is a block of
-          <span class="codefrag ">sitemap.xmap</span> which simply delegates certain requests to
+          independent <span class="codefrag">*.xmap</span> files.  There is a block of
+          <span class="codefrag">sitemap.xmap</span> which simply delegates certain requests to
           these subsitemaps:</p>
 <pre class="code">
       &lt;!-- Body content --&gt;
@@ -689,14 +689,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.</p>
-<p>For instance, the main pipeline in <span class="codefrag ">faq.xmap</span> matches
-            <span class="codefrag ">**.xml</span>, but only <span class="codefrag ">**faq.xml</span> requests are
+<p>For instance, the main pipeline in <span class="codefrag">faq.xmap</span> matches
+            <span class="codefrag">**.xml</span>, but only <span class="codefrag">**faq.xml</span> requests are
             sent to it.</p>
 <p>This "late binding" is useful, because the whole URL space is
-            managed in <span class="codefrag ">sitemap.xmap</span> and not spread over lots of
-            *.xmap files.  For instance, say you wish all <span class="codefrag ">*.xml</span>
-            inside a "<span class="codefrag ">faq/</span>" directory to be processed as FAQs.  Just
-            override <span class="codefrag ">sitemap.xmap</span> and redefine the relevant source
+            managed in <span class="codefrag">sitemap.xmap</span> and not spread over lots of
+            *.xmap files.  For instance, say you wish all <span class="codefrag">*.xml</span>
+            inside a "<span class="codefrag">faq/</span>" directory to be processed as FAQs.  Just
+            override <span class="codefrag">sitemap.xmap</span> and redefine the relevant source
             matcher:</p>
 <pre class="code">
         &lt;map:match pattern="**faq.xml"&gt;
@@ -709,7 +709,7 @@
 <h2 class="underlined_10">Output pipelines</h2>
 <div class="section">
 <p>
-        To recap, we now have a <span class="codefrag ">*.xml</span> pipeline defined for each
+        To recap, we now have a <span class="codefrag">*.xml</span> pipeline defined for each
         page in the site, emitting standardized XML.  These pipeline definitions
         are located in various *.xmap files, notably forrest.xmap
       </p>
@@ -723,7 +723,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
-          <span class="codefrag ">sitemap.xmap</span> ...
+          <span class="codefrag">sitemap.xmap</span> ...
         </p>
 <pre class="code">
 1   &lt;map:match type="regexp" pattern="^(.*?)([^/]*).pdf$"&gt;
@@ -740,11 +740,11 @@
 <ol>
           
 <li>The first line uses a matching regexp to break the URL into
-            directory <span class="codefrag ">(.*?)</span> and filename
-            <span class="codefrag ">([^/]*)</span> parts.</li>
+            directory <span class="codefrag">(.*?)</span> and filename
+            <span class="codefrag">([^/]*)</span> parts.</li>
           
 <li>We then generate XML from a <a href="#source_pipelines">Source
-              pipeline</a>, with the URL <span class="codefrag ">cocoon:/{1}{2}.xml</span>
+              pipeline</a>, with the URL <span class="codefrag">cocoon:/{1}{2}.xml</span>
 </li>
           
 <li>We then expand any XInclude statements..</li>
@@ -760,8 +760,8 @@
 <h3 class="underlined_5">HTML output</h3>
 <p>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 <span class="codefrag ">*.html</span> matcher in
-          <span class="codefrag ">sitemap.xmap</span> ...</p>
+          Here is the <span class="codefrag">*.html</span> matcher in
+          <span class="codefrag">sitemap.xmap</span> ...</p>
 <pre class="code">
           &lt;map:match pattern="*.html"&gt;
             &lt;map:aggregate element="site"&gt;
@@ -780,7 +780,7 @@
           aggregating <a href="body-index.html">body-index.html</a> and
           <a href="menu-index.html">menu-index.html</a> and 
           <a href="tab-index.html">tab-index.html</a> and then applying the
-          <span class="codefrag ">site2xhtml.xsl</span> stylesheet to the result.
+          <span class="codefrag">site2xhtml.xsl</span> stylesheet to the result.
         </p>
 <p>
           There is a nearly identical matcher for HTML files in subdirectories:
@@ -831,7 +831,7 @@
 <li>
             
 <p>We then apply a custom-written
-              <span class="codefrag ">IdGeneratorTransformer</span>, which ensures that every
+              <span class="codefrag">IdGeneratorTransformer</span>, which ensures that every
               &lt;section&gt; has an "id" attribute if one is not supplied, by generating one from the
               &lt;title&gt; if necessary.  For example, &lt;idgen&gt; will
               transform:</p>
@@ -850,9 +850,9 @@
               ...
             </pre>
             
-<p>Later, the <span class="codefrag ">document2html.xsl</span> stylesheet will create
+<p>Later, the <span class="codefrag">document2html.xsl</span> stylesheet will create
               an &lt;a name&gt; element for every section, allowing this section to
-              be referred to as <span class="codefrag ">index.html#How+to+boil+eggs</span>.</p>
+              be referred to as <span class="codefrag">index.html#How+to+boil+eggs</span>.</p>
           
 </li>
           
@@ -867,7 +867,7 @@
 </ol>
 <a name="N10291"></a><a name="menu_pipeline"></a>
 <h3 class="underlined_5">Page menu</h3>
-<p>In the <span class="codefrag ">sitemap.xmap</span> file, the matcher generating HTML for the menu is:</p>
+<p>In the <span class="codefrag">sitemap.xmap</span> file, the matcher generating HTML for the menu is:</p>
 <pre class="code">
       &lt;map:match pattern="**menu-*.html"&gt;
         &lt;map:generate src="cocoon:/{1}book-{2}.html"/&gt;
@@ -880,7 +880,7 @@
       </pre>
 <p>We get XML from a "book" pipeline, 
         <a href="#linkrewriting_impl">rewrite links</a>, and apply the
-          <span class="codefrag ">book2menu.xsl</span> stylesheet to generate HTML.</p>
+          <span class="codefrag">book2menu.xsl</span> stylesheet to generate HTML.</p>
 <p>How the menu XML is actually generated (the *book-*.html pipeline) is
           sufficiently complex to require a 
           <a href="#menu_xml_generation">section of its own</a>.</p>
@@ -897,23 +897,23 @@
        &lt;/map:call&gt;
      &lt;/map:match&gt;
            </pre>
-<p>All the smarts are in the <span class="codefrag ">tab2menu.xsl</span> stylesheet, which
+<p>All the smarts are in the <span class="codefrag">tab2menu.xsl</span> stylesheet, which
           needs to choose the correct tab based on the current path.  Currently,
           a "longest matching path" algorithm is implemented.  See the
-          <span class="codefrag ">tab2menu.xsl</span> stylesheet for details.</p>
+          <span class="codefrag">tab2menu.xsl</span> stylesheet for details.</p>
 </div>
 
     
 <a name="N102D3"></a><a name="menu_xml_generation"></a>
 <h2 class="underlined_10">Menu XML generation</h2>
 <div class="section">
-<p>The "book" pipeline is defined in <span class="codefrag ">sitemap.xmap</span>as:</p>
+<p>The "book" pipeline is defined in <span class="codefrag">sitemap.xmap</span>as:</p>
 <pre class="code">
         &lt;map:match pattern="**book-*.html"&gt;
           &lt;map:mount uri-prefix="" src="menu.xmap" check-reload="yes" /&gt;
         &lt;/map:match&gt;
         </pre>
-<p>Meaning that it is defined in the <span class="codefrag ">menu.xmap</span> file.  In there we find
+<p>Meaning that it is defined in the <span class="codefrag">menu.xmap</span> file.  In there we find
         the real definition, which is quite complicated, because there are three
         supported menu systems (see <a href="../docs_0_70/linking.html">menus and
           linking</a>).  We will not go through the sitemap itself
@@ -924,7 +924,7 @@
           root-relative.</li>
         
 <li>
-<p>Depending on the <span class="codefrag ">forrest.menu-scheme</span> property, we
+<p>Depending on the <span class="codefrag">forrest.menu-scheme</span> property, we
             now apply one of the two algorithms for choosing a set of menu links
             (described in <a href="../docs_0_70/linking.html#menu_generation">menu
               generation</a>):</p>
@@ -942,12 +942,12 @@
               
 <p>
                 For example, say our current page's path is
-                <span class="codefrag ">community/howto/index.html</span>.  In
-                <span class="codefrag ">site.xml</span> we look for the node with this
-                "<span class="codefrag ">href</span>" and discover its "<span class="codefrag ">tab</span>" attribute
-                value is "<span class="codefrag ">howtos</span>".  We then prune the
-                <span class="codefrag ">site.xml</span>-derived content to contain only nodes with
-                <span class="codefrag ">tab="howtos"</span>.
+                <span class="codefrag">community/howto/index.html</span>.  In
+                <span class="codefrag">site.xml</span> we look for the node with this
+                "<span class="codefrag">href</span>" and discover its "<span class="codefrag">tab</span>" attribute
+                value is "<span class="codefrag">howtos</span>".  We then prune the
+                <span class="codefrag">site.xml</span>-derived content to contain only nodes with
+                <span class="codefrag">tab="howtos"</span>.
               </p>
               
 <p>
@@ -967,7 +967,7 @@
 <li>
               
 <p>For "directory" menu generation, we simply use an
-                <span class="codefrag ">XPathTransformer</span> to include only pages in the
+                <span class="codefrag">XPathTransformer</span> to include only pages in the
                 current page's directory, or below:</p>
               
 <pre class="code">
@@ -977,10 +977,10 @@
                 </pre>
               
 <p>
-                Here, the "<span class="codefrag ">{1}</span>" is the directory part of the current
+                Here, the "<span class="codefrag">{1}</span>" is the directory part of the current
                 page.  So if our current page is
-                <span class="codefrag ">community/howto/index.html</span> then "<span class="codefrag ">{1}</span>" will
-                be <span class="codefrag ">community/howto/</span> and the transformer will
+                <span class="codefrag">community/howto/index.html</span> then "<span class="codefrag">{1}</span>" will
+                be <span class="codefrag">community/howto/</span> and the transformer will
                 include all nodes in that directory.
               </p>
             
@@ -988,18 +988,18 @@
           
 </ul>
           
-<p>We now have a <span class="codefrag ">site.xml</span> subset relevant to our current
+<p>We now have a <span class="codefrag">site.xml</span> subset relevant to our current
             page.</p>
         
 </li>
         
-<li>The "<span class="codefrag ">href</span>" nodes in this are then made relative to the
+<li>The "<span class="codefrag">href</span>" nodes in this are then made relative to the
           current page.</li>
         
-<li>The XML is then transformed into a legacy "<span class="codefrag ">book.xml</span>"
+<li>The XML is then transformed into a legacy "<span class="codefrag">book.xml</span>"
           format, for compatibility with existing stylesheets, and this XML
           format is returned (hence the name of the matcher:
-          <span class="codefrag ">**book-*.html</span>).</li>
+          <span class="codefrag">**book-*.html</span>).</li>
       
 </ol>
 </div>
@@ -1008,7 +1008,7 @@
 <a name="N10359"></a><a name="linkrewriting_impl"></a>
 <h2 class="underlined_10">Link rewriting</h2>
 <div class="section">
-<p>In numerous places in <span class="codefrag ">sitemap.xmap</span> you will see the
+<p>In numerous places in <span class="codefrag">sitemap.xmap</span> you will see the
         "linkrewriter" transformer in action.  For example:</p>
 <pre class="code">&lt;map:transform type="linkrewriter" src="cocoon:/{1}linkmap-{2}.html"/&gt;</pre>
 <p>This statement is Cocoon's linking system in action.  A full
@@ -1017,7 +1017,7 @@
 <a name="N10370"></a><a name="input_modules"></a>
 <h3 class="underlined_5">Cocoon foundations: Input Modules</h3>
 <p>
-          The implementation of <span class="codefrag ">site:</span> linking is heavily based on
+          The implementation of <span class="codefrag">site:</span> linking is heavily based on
           Cocoon <a href="http://cocoon.apache.org/2.1/userdocs/concepts/modules.html">Input Modules</a>, 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
@@ -1025,21 +1025,21 @@
           querying an underlying data source.
         </p>
 <p>
-          In particular, Cocoon contains an <span class="codefrag ">XMLFileModule</span>, which
+          In particular, Cocoon contains an <span class="codefrag">XMLFileModule</span>, which
           lets one look up the value of an XML node, by interpreting the key as
           an XPath expression.  Cocoon also has a
-          <span class="codefrag ">SimpleMappingMetaModule</span>, which allows the key to be
+          <span class="codefrag">SimpleMappingMetaModule</span>, which allows the key to be
           rewritten before it is used to look up a value.
         </p>
 <p>
-          The idea for putting these together to rewrite "<span class="codefrag ">site:</span>"
+          The idea for putting these together to rewrite "<span class="codefrag">site:</span>"
           links was described in <a href="http://marc.theaimsgroup.com/?t=103992708800001&r=1&w=2">this
             thread</a>. The idea is to write a Cocoon Transformer that
           triggers on encountering &lt;link
-          href="<span class="codefrag ">scheme:address</span>"&gt;, and interprets the
-          <span class="codefrag ">scheme:address</span> internal URI as
-          <span class="codefrag ">inputmodule:key</span>.  The transformer then uses the named
-          InputModule to look up the key value. The <span class="codefrag ">scheme:address</span>
+          href="<span class="codefrag">scheme:address</span>"&gt;, and interprets the
+          <span class="codefrag">scheme:address</span> internal URI as
+          <span class="codefrag">inputmodule:key</span>.  The transformer then uses the named
+          InputModule to look up the key value. The <span class="codefrag">scheme:address</span>
           URI is then rewritten with the found value.  This transformer was
           implemented as 
           <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15611">LinkRewriterTransformer</a>,
@@ -1048,7 +1048,7 @@
 <a name="N103A4"></a><a name="implement_rewriting"></a>
 <h3 class="underlined_5">Implementing "site:" rewriting</h3>
 <p>
-          Using the above components, "<span class="codefrag ">site:</span>" URI rewriting is
+          Using the above components, "<span class="codefrag">site:</span>" URI rewriting is
           accomplished as follows.
         </p>
 <a name="N103B3"></a><a name="cocoon_xconf"></a>
@@ -1074,26 +1074,26 @@
             
 <li>
 <strong>linkmap</strong> will provide access to the contents of
-              <span class="codefrag ">site.xml</span>; for example, <span class="codefrag ">linkmap:/site/about/index/@href</span>
+              <span class="codefrag">site.xml</span>; for example, <span class="codefrag">linkmap:/site/about/index/@href</span>
               would return the value "index.html".</li>
             
 <li>
 <strong>site</strong> provides a "mask" over
-              <strong>linkmap</strong> such that <span class="codefrag ">site:index</span> expands
-              to <span class="codefrag ">linkmap:/site//index/@href</span>
+              <strong>linkmap</strong> such that <span class="codefrag">site:index</span> expands
+              to <span class="codefrag">linkmap:/site//index/@href</span>
             
 </li>
             
 <li>
 <strong>ext</strong> provides another "mask" over
-              <strong>linkmap</strong>, such that <span class="codefrag ">ext:ant</span> would
-              expand to <span class="codefrag ">linkmap:/site/external-refs//ant/@href</span>
+              <strong>linkmap</strong>, such that <span class="codefrag">ext:ant</span> would
+              expand to <span class="codefrag">linkmap:/site/external-refs//ant/@href</span>
             
 </li>
           
 </ul>
 <p>However at the moment, we have only declared the input modules.
-            They will be configured in <span class="codefrag ">sitemap.xmap</span> as described in
+            They will be configured in <span class="codefrag">sitemap.xmap</span> as described in
             the next section.</p>
 <a name="N103F1"></a><a name="sitemap"></a>
 <h4>sitemap.xmap</h4>
@@ -1150,39 +1150,39 @@
                   &lt;file src="{src}" reloadable="false" /&gt;
               &lt;/input-module&gt;</pre>
               
-<p>The "<span class="codefrag ">{src}</span>" text is expanded to the value of the
-                "<span class="codefrag ">src</span>" attribute in the "<span class="codefrag ">linkrewriter</span>"
-                instance, namely "<span class="codefrag ">cocoon:/{1}linkmap-{2}.html</span>"
-                Thus the <span class="codefrag ">linkmap</span> module reads dynamically
+<p>The "<span class="codefrag">{src}</span>" text is expanded to the value of the
+                "<span class="codefrag">src</span>" attribute in the "<span class="codefrag">linkrewriter</span>"
+                instance, namely "<span class="codefrag">cocoon:/{1}linkmap-{2}.html</span>"
+                Thus the <span class="codefrag">linkmap</span> module reads dynamically
                 generated XML specific to the current request.</p>
             
 </li>
             
 <li>
               
-<p>One level out, we configure the "<span class="codefrag ">site</span>" and
-                "<span class="codefrag ">ext</span>" input modules, to map onto our dynamically
-                configured "<span class="codefrag ">linkmap</span>" module.</p>
+<p>One level out, we configure the "<span class="codefrag">site</span>" and
+                "<span class="codefrag">ext</span>" input modules, to map onto our dynamically
+                configured "<span class="codefrag">linkmap</span>" module.</p>
             
 </li>
             
 <li>
               
 <p>Then at the outermost level, we configure the
-                "<span class="codefrag ">linkrewriter</span>" transformer.  First we tell it which
+                "<span class="codefrag">linkrewriter</span>" transformer.  First we tell it which
                 attributes to consider rewriting:</p>
               
 <pre class="code">
                 &lt;link-attrs&gt;href src&lt;/link-attrs&gt;
                 &lt;schemes&gt;site ext&lt;/schemes&gt;</pre>
               
-<p>So, "<span class="codefrag ">href</span>" and "<span class="codefrag ">src</span>" attributes starting
-                with "<span class="codefrag ">site:</span>" or "<span class="codefrag ">ext:</span>" are rewritten.</p>
+<p>So, "<span class="codefrag">href</span>" and "<span class="codefrag">src</span>" attributes starting
+                with "<span class="codefrag">site:</span>" or "<span class="codefrag">ext:</span>" are rewritten.</p>
 
               
-<p>By nesting the "<span class="codefrag ">site</span>" and "<span class="codefrag ">ext</span>" input
-                modules in the "<span class="codefrag ">linkrewriter</span>" configuration, we tell
-                "<span class="codefrag ">linkrewriter</span>" to use these two input modules when
+<p>By nesting the "<span class="codefrag">site</span>" and "<span class="codefrag">ext</span>" input
+                modules in the "<span class="codefrag">linkrewriter</span>" configuration, we tell
+                "<span class="codefrag">linkrewriter</span>" to use these two input modules when
                 rewriting links.</p>
             
 </li>
@@ -1190,20 +1190,20 @@
 </ul>
 <p>
             The end result is that, for example, the source XML for the
-            <span class="codefrag ">community/body-index.html</span> page has its links rewritten
+            <span class="codefrag">community/body-index.html</span> page has its links rewritten
             by an XMLFileModule reading XML from
-            <span class="codefrag ">cocoon:/community/linkmap-index.html</span>
+            <span class="codefrag">cocoon:/community/linkmap-index.html</span>
           
 </p>
 <a name="N10464"></a><a name="dynamic_linkmap"></a>
 <h4>Dynamically generating a linkmap</h4>
 <p>
             Why do we need this "linkmap" pipeline generating dynamic XML from
-            <span class="codefrag ">site.xml</span>, instead of just using <span class="codefrag ">site.xml</span> directly?  The reasons are described
+            <span class="codefrag">site.xml</span>, instead of just using <span class="codefrag">site.xml</span> directly?  The reasons are described
             in <a href="http://marc.theaimsgroup.com/?l=forrest-dev&m=103444028129281&w=2">the linkmap RT</a>: 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 <span class="codefrag ">linkmap.xmap</span> ...
+            pipelines in <span class="codefrag">linkmap.xmap</span> ...
           </p>
 <pre class="code">
 &lt;!-- site.xml with @href's appended to be context-relative. --&gt;

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

Modified: forrest/site/docs_0_70/upgrading_07.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_70/upgrading_07.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_70/upgrading_07.html (original)
+++ forrest/site/docs_0_70/upgrading_07.html Sun Dec 18 17:31:25 2005
@@ -427,7 +427,7 @@
 <p>
       Take advantage of the separation of concerns. In a new workspace,
       create a fresh
-      '<span class="codefrag ">forrest seed</span>' site, then tweak its forrest.properties
+      '<span class="codefrag">forrest seed</span>' 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.



Mime
View raw message