[DOCUMENTATION] English:

- manual fixes

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@15827 44c647ce-9c0f-0410-b52a-842ac1e357ba

documentation/manual/en/module_specs/Zend_Config-Introduction.xml

@@ -3,21 +3,24 @@
 <sect1 id="zend.config.introduction">
     <title>Introduction</title>
     <para>
-        <classname>Zend_Config</classname> is designed to simplify the access to, and the use of, configuration data within applications.
-        It provides a nested object property based user interface for accessing this configuration data within
-        application code. The configuration data may come from a variety of media supporting hierarchical data storage.
-        Currently <classname>Zend_Config</classname> provides adapters for configuration data that are stored in text files with
-        <link linkend="zend.config.adapters.ini"><classname>Zend_Config_Ini</classname></link> and
+        <classname>Zend_Config</classname> is designed to simplify the access to, and the use of,
+        configuration data within applications. It provides a nested object property based user
+        interface for accessing this configuration data within application code. The configuration
+        data may come from a variety of media supporting hierarchical data storage. Currently
+        <classname>Zend_Config</classname> provides adapters for configuration data that are stored
+        in text files with <link
+            linkend="zend.config.adapters.ini"><classname>Zend_Config_Ini</classname></link> and
         <link linkend="zend.config.adapters.xml"><classname>Zend_Config_Xml</classname></link>.
     </para>
     <example id="zend.config.introduction.example.using">
         <title>Using Zend_Config</title>
         <para>
-            Normally it is expected that users would use one of the adapter classes such as
-            <link linkend="zend.config.adapters.ini"><classname>Zend_Config_Ini</classname></link> or
-            <link linkend="zend.config.adapters.xml"><classname>Zend_Config_Xml</classname></link>, but if configuration data are
-            available in a PHP array, one may simply pass the data to the <classname>Zend_Config</classname> constructor in order
-            to utilize a simple object-oriented interface:
+            Normally it is expected that users would use one of the adapter classes such as <link
+                linkend="zend.config.adapters.ini"><classname>Zend_Config_Ini</classname></link> or
+            <link linkend="zend.config.adapters.xml"><classname>Zend_Config_Xml</classname></link>,
+            but if configuration data are available in a PHP array, one may simply pass the data to
+            the <classname>Zend_Config</classname> constructor in order to utilize a simple
+            object-oriented interface:
         </para>
         <programlisting language="php"><![CDATA[
 // Given an array of configuration data
@@ -50,12 +53,13 @@ $db = Zend_Db::factory($config->database);
 ]]></programlisting>
     </example>
     <para>
-        As illustrated in the example above, <classname>Zend_Config</classname> provides nested object property syntax to access
-        configuration data passed to its constructor.
+        As illustrated in the example above, <classname>Zend_Config</classname> provides nested
+        object property syntax to access configuration data passed to its constructor.
     </para>
     <para>
-        Along with the object oriented access to the data values, <classname>Zend_Config</classname> also has <code>get()</code>
-        which will return the supplied default value if the data element doesn't exist. For example:
+        Along with the object oriented access to the data values,
+        <classname>Zend_Config</classname> also has <methodname>get()</methodname> which will
+        return the supplied default value if the data element doesn't exist. For example:
     </para>
     <programlisting language="php"><![CDATA[
 $host = $config->database->get('host', 'localhost');
@@ -63,8 +67,8 @@ $host = $config->database->get('host', 'localhost');
     <example id="zend.config.introduction.example.file.php">
         <title>Using Zend_Config with a PHP Configuration File</title>
         <para>
-            It is often desirable to use a pure PHP-based configuration file. The following code illustrates how easily
-            this can be accomplished:
+            It is often desirable to use a pure PHP-based configuration file. The following code
+            illustrates how easily this can be accomplished:
         </para>
         <programlisting language="php"><![CDATA[
 // config.php

documentation/manual/en/module_specs/Zend_Config_Ini.xml

@@ -7,25 +7,25 @@
         them in the application by using nested object property syntax. The INI format is specialized to provide both
         the ability to have a hierarchy of configuration data keys and inheritance between configuration data sections.
         Configuration data hierarchies are supported by separating the keys with the dot or period character
-        (<code>.</code>). A section may extend or inherit from another section by following the section name with a
-        colon character (<code>:</code>) and the name of the section from which data are to be inherited.
+        ("<emphasis>.</emphasis>"). A section may extend or inherit from another section by following the section name with a
+        colon character ("<emphasis>:</emphasis>) and the name of the section from which data are to be inherited.
     </para>
     <note>
         <title>Parsing the INI File</title>
         <para>
             <classname>Zend_Config_Ini</classname> utilizes the
-            <ulink url="http://php.net/parse_ini_file"><code>parse_ini_file()</code></ulink>
+            <ulink url="http://php.net/parse_ini_file"><methodname>parse_ini_file()</methodname></ulink>
             PHP function. Please review this documentation to be aware of its specific behaviors,
             which propagate to <classname>Zend_Config_Ini</classname>, such as how the special values of
-            <constant>TRUE</constant>, <constant>FALSE</constant>, <code>yes</code>, <code>no</code>,
-            and <constant>NULL</constant> are handled.
+            "<constant>TRUE</constant>", "<constant>FALSE</constant>", "yes", "no",
+            and "<constant>NULL</constant>" are handled.
         </para>
     </note>
     <note>
         <title>Key Separator</title>
         <para>
-            By default, the key separator character is the period character (<code>.</code>). This can be changed,
-            however, by changing the <varname>$options</varname> key <code>'nestSeparator'</code> when constructing the
+            By default, the key separator character is the period character ("<emphasis>.</emphasis>"). This can be changed,
+            however, by changing the <varname>$options</varname> key <emphasis>'nestSeparator'</emphasis> when constructing the
             <classname>Zend_Config_Ini</classname> object. For example:
             <programlisting language="php"><![CDATA[
 $options['nestSeparator'] = ':';
@@ -44,7 +44,7 @@ $config = new Zend_Config_Ini('/path/to/config.ini',
             section inherits from the production section. In this case, the decision is arbitrary and could have been
             written conversely, with the production section inheriting from the staging section, though this may not be
             the case for more complex situations. Suppose, then, that the following configuration data are contained in
-            <code>/path/to/config.ini</code>:
+            <filename>/path/to/config.ini</filename>:
         </para>
         <programlisting language="ini"><![CDATA[
 ; Production site configuration data

documentation/manual/en/module_specs/Zend_Config_Writer.xml

@@ -8,10 +8,10 @@
         adapter-less system and thus is very easy to use. By default
         <classname>Zend_Config_Writer</classname> ships with three adapters, which all
         work the same. You instantiate a writer with specific options, which
-        can be <code>filename</code> and <code>config</code>. Then
-        you call the <code>write()</code> method of the writer and the config
+        can be <emphasis>filename</emphasis> and <emphasis>config</emphasis>. Then
+        you call the <methodname>write()</methodname> method of the writer and the config
         file is created. You can also give <varname>$filename</varname> and
-        <varname>$config</varname> directly to the <code>write()</code> method.
+        <varname>$config</varname> directly to the <methodname>write()</methodname> method.
         Currently the following writers are shipped with
         <classname>Zend_Config_Writer</classname>:
     </para>
@@ -36,7 +36,7 @@
 
     <para>
         As an exception, <classname>Zend_Config_Writer_Ini</classname> has an additional
-        option parameter <code>nestSeparator</code>, which defines with which
+        option parameter <emphasis>nestSeparator</emphasis>, which defines with which
         character the single nodes are separated. The default is a single dot,
         like it is accepted by <classname>Zend_Config_Ini</classname> by default.
     </para>
@@ -45,10 +45,10 @@
         When modifying or creating a <classname>Zend_Config</classname> object, there are
         some things to know. To create or modify a value, you simply say set
         the parameter of the <classname>Zend_Config</classname> object via the parameter
-        accessor (<code>-&gt;</code>). To create a section in the root or to
+        accessor (<emphasis>-&gt;</emphasis>). To create a section in the root or to
         create a branch, you just create a new array
-        (<code>$config-&gt;branch = array();</code>). To define which section
-        extends another one, you call the <code>setExtend()</code> method
+        ("$config-&gt;branch = array();"). To define which section
+        extends another one, you call the <methodname>setExtend()</methodname> method
         on the root <classname>Zend_Config</classname> object.
     </para>
 
@@ -123,7 +123,7 @@ $writer->write();
             When loading an existing config file for modifications it is very
             important to load all sections and to skip the extends, so that
             no values are merged. This is done by giving the
-            <code>skipExtends</code> as option to the constructor.
+            <emphasis>skipExtends</emphasis> as option to the constructor.
         </para>
     </note>
 </sect1>

documentation/manual/en/module_specs/Zend_Config_Xml.xml

@@ -3,31 +3,36 @@
 <sect1 id="zend.config.adapters.xml">
     <title>Zend_Config_Xml</title>
     <para>
-        <classname>Zend_Config_Xml</classname> enables developers to store configuration data in a simple XML format and read them
-        via nested object property syntax. The root element of the XML file or string is irrelevant and may be named arbitrarily.
-        The first level of XML elements correspond with configuration data sections. The XML format supports
-        hierarchical organization through nesting of XML elements below the section-level elements. The content of a
-        leaf-level XML element corresponds to the value of a configuration datum. Section inheritance is supported by a
-        special XML attribute named <code>extends</code>, and the value of this attribute corresponds with the section
-        from which data are to be inherited by the extending section.
+        <classname>Zend_Config_Xml</classname> enables developers to store configuration data in a
+        simple XML format and read them via nested object property syntax. The root element of the
+        XML file or string is irrelevant and may be named arbitrarily. The first level of XML
+        elements correspond with configuration data sections. The XML format supports hierarchical
+        organization through nesting of XML elements below the section-level elements. The content
+        of a leaf-level XML element corresponds to the value of a configuration datum. Section
+        inheritance is supported by a special XML attribute named <emphasis>extends</emphasis>, and
+        the value of this attribute corresponds with the section from which data are to be
+        inherited by the extending section.
     </para>
     <note>
         <title>Return Type</title>
         <para>
-            Configuration data read into <classname>Zend_Config_Xml</classname> are always returned as strings.
-            Conversion of data from strings to other types is left to developers to suit their particular needs.
+            Configuration data read into <classname>Zend_Config_Xml</classname> are always returned
+            as strings. Conversion of data from strings to other types is left to developers to
+            suit their particular needs.
         </para>
     </note>
     <example id="zend.config.adapters.xml.example.using">
         <title>Using Zend_Config_Xml</title>
         <para>
-            This example illustrates a basic use of <classname>Zend_Config_Xml</classname> for loading configuration data from an
-            XML file. In this example there are configuration data for both a production system and for a staging
-            system. Because the staging system configuration data are very similar to those for production, the staging
-            section inherits from the production section. In this case, the decision is arbitrary and could have been
-            written conversely, with the production section inheriting from the staging section, though this may not be
-            the case for more complex situations. Suppose, then, that the following configuration data are contained in
-            <code>/path/to/config.xml</code>:
+            This example illustrates a basic use of <classname>Zend_Config_Xml</classname> for
+            loading configuration data from an XML file. In this example there are configuration
+            data for both a production system and for a staging system. Because the staging system
+            configuration data are very similar to those for production, the staging section
+            inherits from the production section. In this case, the decision is arbitrary and could
+            have been written conversely, with the production section inheriting from the staging
+            section, though this may not be the case for more complex situations. Suppose, then,
+            that the following configuration data are contained in
+            <filename>/path/to/config.xml</filename>:
         </para>
         <programlisting language="xml"><![CDATA[
 <?xml version="1.0"?>
@@ -56,8 +61,9 @@
 </configdata>
 ]]></programlisting>
         <para>
-            Next, assume that the application developer needs the staging configuration data from the XML file. It is a
-            simple matter to load these data by specifying the XML file and the staging section:
+            Next, assume that the application developer needs the staging configuration data from
+            the XML file. It is a simple matter to load these data by specifying the XML file and
+            the staging section:
         </para>
         <programlisting language="php"><![CDATA[
 $config = new Zend_Config_Xml('/path/to/config.xml', 'staging');
@@ -69,11 +75,12 @@ echo $config->database->params->dbname; // prints "dbname"
     <example id="zend.config.adapters.xml.example.attributes">
         <title>Using Tag Attributes in Zend_Config_Xml</title>
         <para>
-            <classname>Zend_Config_Xml</classname> also supports two additional ways of defining nodes in the configuration. Both make use
-            of attributes. Since the <code>extends</code> and the <code>value</code> attributes are reserved keywords
-            (the latter one by the the second way of using attributes), they may not be used. The first way of
-            making usage of attributes is to add attributes in a parent node, which then will be translated into
-            children of that node:
+            <classname>Zend_Config_Xml</classname> also supports two additional ways of defining
+            nodes in the configuration. Both make use of attributes. Since the
+            <emphasis>extends</emphasis> and the <emphasis>value</emphasis> attributes are reserved
+            keywords (the latter one by the the second way of using attributes), they may not be
+            used. The first way of making usage of attributes is to add attributes in a parent
+            node, which then will be translated into children of that node:
         </para>
         <programlisting language="xml"><![CDATA[
 <?xml version="1.0"?>
@@ -91,9 +98,9 @@ echo $config->database->params->dbname; // prints "dbname"
 </configdata>
 ]]></programlisting>
         <para>
-            The other way does not really shorten the config, but keeps it easier to maintain since you don't have to write
-            the tag name twice. You simply create an empty tag with the value in the <code>value</code>
-            attribute:
+            The other way does not really shorten the config, but keeps it easier to maintain since
+            you don't have to write the tag name twice. You simply create an empty tag with the
+            value in the <emphasis>value</emphasis> attribute:
         </para>
         <programlisting language="xml"><![CDATA[
 <?xml version="1.0"?>
@@ -128,7 +135,7 @@ echo $config->database->params->dbname; // prints "dbname"
             <classname>Zend_Config_Xml</classname> is able to load an XML string directly,
             such as that retrieved from a database. The string is passed
             as the first parameter to the constructor and must start with the
-            characters <code>'&lt;?xml'</code>:
+            characters <emphasis>'&lt;?xml'</emphasis>:
         </para>
         <programlisting language="xml"><![CDATA[
 $string = <<<EOT