delete empty lines DOC-ES

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

documentation/manual/es/module_specs/Zend_Acl-Advanced.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 15814 -->
-<!-- Reviewed: no -->
+    <!-- EN-Revision: 15814 -->
+    <!-- Reviewed: no -->
 <sect1 id="zend.acl.advanced">
 
     <title>Uso Avanzado</title>
@@ -9,24 +9,46 @@
 
         <title>Almacenamiento Permanente de los Datos ACL</title>
 
-       <para>
-            <classname>Zend_Acl</classname> fue diseñado de tal manera que no requiere ninguna
-            tecnología particular como bases de datos o un servidor de cache para el almacenamiento
-            de datos <acronym>ACL</acronym>. Al poseer una implementación completamente construida
-            en <acronym>PHP</acronym>, es posible construir herramientas de administración
-            personalizadas sobre <classname>Zend_Acl</classname> con relativa facilidad y
-            flexibilidad. En muchas situaciones se requiere alguna forma de mantenimiento
-            interactivo de una <acronym>ACL</acronym>, y <classname>Zend_Acl</classname> provee
-            métodos para configurar, y consultar, los controles de acceso de una aplicación.</para>
-
-       <para>El almacenamiento de los datos <acronym>ACL</acronym> es una tarea que se delega al
-            desarrollador, puesto que la utilización variará extensamente en distintas situaciones.
-            Dado que <classname>Zend_Acl</classname> es serializable, los objetos
-                <acronym>ACL</acronym> pueden serializarse con la función <ulink
-                url="http://php.net/serialize">
+        <para>
+            <classname>Zend_Acl</classname>
+            fue diseñado de tal manera que no requiere ninguna tecnología particular como bases de
+            datos o un servidor de cache para el almacenamiento de datos
+            <acronym>ACL</acronym>
+            . Al poseer una implementación completamente construida en
+            <acronym>PHP</acronym>
+            , es posible construir herramientas de administración personalizadas sobre
+            <classname>Zend_Acl</classname>
+            con relativa facilidad y
+            flexibilidad. En muchas situaciones se requiere alguna forma de
+            mantenimiento
+            interactivo de una
+            <acronym>ACL</acronym>
+            , y
+            <classname>Zend_Acl</classname>
+            provee
+            métodos para configurar, y consultar, los controles de acceso de una aplicación.
+        </para>
+
+        <para>
+            El almacenamiento de los datos
+            <acronym>ACL</acronym>
+            es una tarea que se delega al
+            desarrollador, puesto que la utilización variará
+            extensamente en distintas situaciones.
+            Dado que
+            <classname>Zend_Acl</classname>
+            es serializable, los objetos
+            <acronym>ACL</acronym>
+            pueden serializarse con la función
+            <ulink url="http://php.net/serialize">
                 <methodname>serialize()</methodname>
-            </ulink> de <acronym>PHP</acronym>, y los resultados pueden ser almacenados donde sea
-            que el desarrollador lo desee, en un archivo, base de datos, o mecanismo de cache</para>
+            </ulink>
+            de
+            <acronym>PHP</acronym>
+            , y los resultados pueden ser almacenados donde sea
+            que el desarrollador lo desee, en un
+            archivo, base de datos, o mecanismo de cache
+        </para>
 
     </sect2>
 
@@ -34,18 +56,32 @@
 
         <title> Escribiendo reglas condicionales ACL con aserciones </title>
 
-       <para>A veces, una regla para permitir o negar una función de acceso a un recurso no
-            debería ser absoluta sino que depende de varios criterios. Por ejemplo, supóngase que
-            debe permitirse cierto acceso, pero únicamente entre las 8:00am y 5:00pm. Otro ejemplo
-            sería negar el acceso debido a una petición que proviene de una dirección IP que se ha
-            marcado como una fuente de abusos. <classname>Zend_Acl</classname> tiene soporte para la
-            aplicación de normas basadas en cualquier condición que el desarrollador necesite.</para>
-
-       <para>
-            <classname>Zend_Acl</classname> provee soporte para reglas condicionales con
-                <classname>Zend_Acl_Assert_Interface</classname> . Con el fin de utilizar la regla
-            de aserción de la interfaz, un desarrollador escribe una clase que implemente el método
-                <methodname>assert()</methodname> de la interfaz:</para>
+        <para>
+            A veces, una regla para permitir o negar una función de acceso a un recurso no debería
+            ser absoluta sino que depende de varios criterios. Por ejemplo, supóngase que
+            debe
+            permitirse cierto
+            acceso, pero únicamente entre las 8:00am y 5:00pm. Otro ejemplo
+            sería
+            negar el acceso debido a una petición que proviene de una dirección IP que se ha
+            marcado
+            como una fuente de abusos.
+            <classname>Zend_Acl</classname>
+            tiene soporte para la
+            aplicación de normas basadas en cualquier condición que el
+            desarrollador necesite.
+        </para>
+
+        <para>
+            <classname>Zend_Acl</classname>
+            provee soporte para reglas condicionales con
+            <classname>Zend_Acl_Assert_Interface</classname>
+            . Con el fin de utilizar la regla
+            de aserción de la interfaz, un desarrollador escribe
+            una clase que implemente el método
+            <methodname>assert()</methodname>
+            de la interfaz:
+        </para>
 
         <programlisting language="php"><![CDATA[
 class CleanIPAssertion implements Zend_Acl_Assert_Interface
@@ -65,32 +101,48 @@ class CleanIPAssertion implements Zend_Acl_Assert_Interface
 }
 ]]></programlisting>
 
-       <para>Una vez la clase de aserción esta disponible, el desarrollador puede suministrar una
+        <para>
+            Una vez la clase de aserción esta disponible, el desarrollador puede suministrar una
             instancia de la clase de aserción cuando asigna reglas condicionales. Una regla que es
-            creada con una aserción sólo se aplica cuando el método de la aserción devuelve
-                <constant>TRUE</constant>.</para>
+            creada con una
+            aserción sólo se aplica cuando el método de la aserción devuelve
+            <constant>TRUE</constant>
+            .
+        </para>
 
         <programlisting language="php"><![CDATA[
 $acl = new Zend_Acl();
 $acl->allow(null, null, null, new CleanIPAssertion());
 ]]></programlisting>
 
-       <para>El código anterior crea una regla condicional que permite el acceso a todos los
+        <para>El código anterior crea una regla condicional que permite el acceso a todos los
             privilegios sobre todo, por todo el mundo, excepto cuando la IP de quien hace la
-            petición está en la "lista negra". Si una petición viene desde una IP que no está
+            petición está en la "lista
+            negra". Si una petición viene desde una IP que no está
             considerada "limpia", entonces la regla no se aplica. Dado que la regla se aplica a
-            todos los roles, todos los recursos, y todos los privilegios, una IP "no limpia" daría
+            todos los roles, todos los recursos, y todos los
+            privilegios, una IP "no limpia" daría
             lugar a una negación de acceso. Éste es un caso especial, sin embargo, y debería ser
-            entendido que en todos los otros casos (por ejemplo, cuando un rol específico, recurso,
-            o privilegio está especificado por la regla), una aserción fallida provoca que la regla
-            no se aplique, y otras reglas deberían ser usadas para determinar si el acceso está
+            entendido que en todos los otros casos (por ejemplo, cuando un rol
+            específico, recurso, o
+            privilegio está especificado por la regla), una aserción fallida provoca que la regla
+            no
+            se aplique, y otras reglas deberían ser usadas para determinar si el acceso
+            está
             permitido o denegado.</para>
 
-       <para>El método <methodname>assert()</methodname> de un objeto aserción es pasado a la
-                <acronym>ACL</acronym>, regla, recurso, y privilegio para el cual una consulta de
-            autorización (por ejemplo, <methodname>isAllowed()</methodname> ) se aplica, con el fin
-            de proporcionar un contexto para que la clase de aserción determine sus condiciones
-            cuando fuera necesario.</para>
+        <para>
+            El método
+            <methodname>assert()</methodname>
+            de un objeto aserción es pasado a la
+            <acronym>ACL</acronym>
+            , regla, recurso, y privilegio para el cual una consulta de
+            autorización (por ejemplo,
+            <methodname>isAllowed()</methodname>
+            ) se aplica, con el fin de proporcionar un contexto para que la clase de aserción
+            determine sus condiciones
+            cuando fuera necesario.
+        </para>
 
     </sect2>
 

documentation/manual/es/module_specs/Zend_Acl-Refining.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 18389 -->
-<!-- Reviewed: no -->
+    <!-- EN-Revision: 18389 -->
+    <!-- Reviewed: no -->
 <sect1 id="zend.acl.refining">
 
     <title>Perfeccionamiento de los controles de acceso</title>
@@ -9,26 +9,44 @@
 
         <title>Definir mejor los controles de acceso</title>
 
-       <para>El <acronym>ACL</acronym> básico según lo definido en la <link
-                linkend="zend.acl.introduction"> sección anterior </link>
+        <para>
+            El
+            <acronym>ACL</acronym>
+            básico según lo definido en la
+            <link linkend="zend.acl.introduction"> sección anterior </link>
             demuestra cómo los diversos privilegios se pueden otorgar sobre todo
-            el <acronym>ACL</acronym> (todos los recursos). En la práctica, sin
-            embargo, los controles de acceso tienden a tener excepciones y
-            diversos grados de complejidad. <classname>Zend_Acl</classname>
+            el
+            <acronym>ACL</acronym>
+            (todos los recursos). En la práctica, sin
+            embargo, los controles de acceso tienden a
+            tener excepciones y
+            diversos grados de complejidad.
+            <classname>Zend_Acl</classname>
             permite lograr estos refinamientos de una manera sencilla y
-            flexible.</para>
-
-       <para>Para el <acronym>CMS</acronym> del ejemplo se ha determinado que,
-            si bien el grupo 'staff' cubre las necesidades de la gran mayoría de
+            flexible.
+        </para>
+
+        <para>
+            Para el
+            <acronym>CMS</acronym>
+            del ejemplo se ha determinado que,
+            si bien el grupo 'staff' cubre las necesidades de la
+            gran mayoría de
             usuarios, hay una necesidad de un nuevo grupo 'marketing' que
-            requiere el acceso al boletín de noticias y las últimas noticias en
-            el CMS. El grupo es bastante auto suficiente y tendrá la capacidad
-            de publicar y de archivar los boletines de noticias y las últimas
-            noticias.</para>
-
-       <para>Primero revisamos el registro del rol para reflejar estos
-            cambios. Hemos determinado que el grupo 'marketing' tiene los mismos
-            permisos básicos que 'staff', así que definimos 'marketing' de tal
+            requiere el
+            acceso al boletín de noticias y las últimas noticias en
+            el CMS. El grupo es bastante auto
+            suficiente y tendrá la capacidad
+            de publicar y de archivar los boletines de noticias y
+            las últimas
+            noticias.
+        </para>
+
+        <para>Primero revisamos el registro del rol para reflejar estos
+            cambios. Hemos determinado
+            que el grupo 'marketing' tiene los mismos
+            permisos básicos que 'staff', así que definimos
+            'marketing' de tal
             manera que herede los permisos de 'staff':</para>
 
         <programlisting language="php"><![CDATA[
@@ -36,9 +54,11 @@
  $acl->addRole(new Zend_Acl_Role('marketing'), 'staff');
 ]]></programlisting>
 
-       <para>A continuación, la nota que por encima de los controles de acceso
-            se refieren a recursos específicos (por ejemplo, "boletín
-            informativo", "últimas noticias", "anuncio de noticias"). Ahora
+        <para>A continuación, la nota que por encima de los controles de acceso
+            se refieren a
+            recursos específicos (por ejemplo, "boletín
+            informativo", "últimas noticias", "anuncio de
+            noticias"). Ahora
             añadimos estos recursos:</para>
 
         <programlisting language="php"><![CDATA[
@@ -56,8 +76,13 @@ $acl->addResource(new Zend_Acl_Resource('latest'), 'news');
 $acl->addResource(new Zend_Acl_Resource('announcement'), 'news');
 ]]></programlisting>
 
-       <para>Entonces es simplemente una cuestión de la definición de estas
-            normas más específicas en ámbitos de la <acronym>ACL</acronym>:</para>
+        <para>
+            Entonces es simplemente una cuestión de la definición de estas
+            normas más específicas en
+            ámbitos de la
+            <acronym>ACL</acronym>
+            :
+        </para>
 
         <programlisting language="php"><![CDATA[
  //
@@ -76,8 +101,12 @@ $acl->addResource(new Zend_Acl_Resource('announcement'), 'news');
  $acl->deny(null, 'announcement', 'archive');
 ]]></programlisting>
 
-       <para>Ahora podemos consultar el <acronym>ACL</acronym> con respecto a
-            los últimos cambios:</para>
+        <para>
+            Ahora podemos consultar el
+            <acronym>ACL</acronym>
+            con respecto a
+            los últimos cambios:
+        </para>
 
         <programlisting language="php"><![CDATA[
  echo $acl->isAllowed('staff', 'newsletter', 'publish') ?
@@ -120,13 +149,23 @@ $acl->addResource(new Zend_Acl_Resource('announcement'), 'news');
 
         <title>Eliminar los controles de acceso</title>
 
-       <para>Para eliminar una o más reglas <acronym>ACL</acronym>,
-            simplemente utilice el método <methodname>removeAllow()</methodname>
-            o <methodname>removeDeny()</methodname>. Al igual que con
-                <methodname>allow()</methodname> y
-                <methodname>deny()</methodname>, puede utilizar un valor
-                <constant>NULL</constant> para indicar que el método es
-            aplicable a todos los roles, recursos y/o privilegios:</para>
+        <para>
+            Para eliminar una o más reglas
+            <acronym>ACL</acronym>
+            ,
+            simplemente utilice el método
+            <methodname>removeAllow()</methodname>
+            o
+            <methodname>removeDeny()</methodname>
+            . Al igual que con
+            <methodname>allow()</methodname>
+            y
+            <methodname>deny()</methodname>
+            , puede utilizar un valor
+            <constant>NULL</constant>
+            para indicar que el método es
+            aplicable a todos los roles, recursos y/o privilegios:
+        </para>
 
         <programlisting language="php"><![CDATA[
 // Elimina la prohibición de leer las últimas noticias de staff (y marketing,
@@ -154,10 +193,14 @@ echo $acl->isAllowed('marketing', 'newsletter', 'archive') ?
 
 ]]></programlisting>
 
-       <para>Los privilegios pueden ser modificados de manera incremental como
-            se ha indicado anteriormente, pero un valor
-                <constant>NULL</constant> para los privilegios anula tales
-            cambios incrementales:</para>
+        <para>
+            Los privilegios pueden ser modificados de manera incremental como
+            se ha indicado
+            anteriormente, pero un valor
+            <constant>NULL</constant>
+            para los privilegios anula tales
+            cambios incrementales:
+        </para>
 
         <programlisting language="php"><![CDATA[
 //Permitir al grupo de "marketing" todos los permisos a las últimas noticias

documentation/manual/es/module_specs/Zend_Acl.xml

@@ -1,109 +1,203 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 18729 -->
-<!-- Reviewed: no -->
+    <!-- EN-Revision: 18729 -->
+    <!-- Reviewed: no -->
 <sect1 id="zend.acl.introduction">
     <title>Introducción</title>
-   <para>
-        <classname>Zend_Acl</classname> provee la implementación de un sistema
+    <para>
+        <classname>Zend_Acl</classname>
+        provee la implementación de un sistema
         simple y flexible de Listas de Control de Acceso
-        (<acronym>ACL</acronym>, por sus siglas en inglés) para la
-        administración de privilegios. En general, una aplicación puede utilizar
-        las <acronym>ACL</acronym> para controlar el acceso a ciertos objetos
-        protegidos, que son requeridos por otros objetos.</para>
-   <para>Para los propósitos de esta documentación: <itemizedlist>
+        (
+        <acronym>ACL</acronym>
+        , por sus siglas en inglés) para la
+        administración de privilegios. En general, una aplicación
+        puede utilizar
+        las
+        <acronym>ACL</acronym>
+        para controlar el acceso a ciertos objetos
+        protegidos, que son requeridos por otros objetos.
+    </para>
+    <para>
+        Para los propósitos de esta documentación:
+        <itemizedlist>
             <listitem>
-               <para>Un <emphasis>recurso</emphasis> es un objeto al cual el
-                    acceso esta controlado.</para>
+                <para>
+                    Un
+                    <emphasis>recurso</emphasis>
+                    es un objeto al cual el
+                    acceso esta controlado.
+                </para>
             </listitem>
             <listitem>
-               <para>Un <emphasis>rol</emphasis> es un objeto que puede
-                    solicitar acceso a un recurso.</para>
+                <para>
+                    Un
+                    <emphasis>rol</emphasis>
+                    es un objeto que puede
+                    solicitar acceso a un recurso.
+                </para>
             </listitem>
-        </itemizedlist> En términos generales, <emphasis> Los roles solicitan
-            acceso a los recursos </emphasis> . Por ejemplo, si una persona
-        solicita acceso a un automóvil, entonces la persona se convierte en el
+        </itemizedlist>
+        En términos generales,
+        <emphasis> Los roles solicitan
+            acceso a los recursos </emphasis>
+        . Por ejemplo, si una persona
+        solicita acceso a un automóvil, entonces la persona se
+        convierte en el
         rol solicitante, y el automóvil en el recurso, puesto que el acceso al
-        automóvil puede no estar disponible a cualquiera.</para>
-
-   <para>A través de la especificación y uso de Listas de Control de Acceso
-            (<acronym>ACL</acronym>), una aplicación puede controlar cómo los
-        objetos solicitantes (roles) han obtenido acceso a objetos protegidos
-        (recursos).</para>
+        automóvil puede no estar disponible a cualquiera.
+    </para>
+
+    <para>
+        A través de la especificación y uso de Listas de Control de Acceso
+        (
+        <acronym>ACL</acronym>
+        ), una aplicación puede controlar cómo los
+        objetos solicitantes (roles) han obtenido acceso a
+        objetos protegidos
+        (recursos).
+    </para>
 
     <sect2 id="zend.acl.introduction.resources">
         <title>Acerca de los Recursos</title>
-       <para>En <classname>Zend_Acl</classname>, crear un recurso es muy
-            sencillo. <classname>Zend_Acl</classname> proporciona el
-                <classname>Zend_Acl_Resource_Interface</classname> para
+        <para>
+            En
+            <classname>Zend_Acl</classname>
+            , crear un recurso es muy
+            sencillo.
+            <classname>Zend_Acl</classname>
+            proporciona el
+            <classname>Zend_Acl_Resource_Interface</classname>
+            para
             facilitar a los desarrolladores la creación de recursos. Una clase
-            solo necesita implementar su interfaz, la cual consiste en un método
-            único, <methodname>getResourceId()</methodname> , para que
-                <classname>Zend_Acl</classname> considere el objeto como un
-            recurso. Adicionalmente, <classname>Zend_Acl_Resource</classname> es
-            proporcionado por <classname>Zend_Acl</classname> como un recurso
+            solo necesita
+            implementar su interfaz, la cual consiste en un método
+            único,
+            <methodname>getResourceId()</methodname>
+            , para que
+            <classname>Zend_Acl</classname>
+            considere el objeto como un
+            recurso. Adicionalmente,
+            <classname>Zend_Acl_Resource</classname>
+            es
+            proporcionado por
+            <classname>Zend_Acl</classname>
+            como un recurso
             básico de aplicación para que los desarrolladores puedan extenderla
-            hasta donde lo deseen.</para>
-       <para>
-            <classname>Zend_Acl</classname> provee un estructura de árbol a la
-            cual pueden ser agregados múltiples recursos (o "Áreas con Controles
+            hasta
+            donde lo deseen.
+        </para>
+        <para>
+            <classname>Zend_Acl</classname>
+            provee un estructura de árbol a la
+            cual pueden ser agregados múltiples recursos (o "Áreas
+            con Controles
             de Acceso").Ya que los recursos son almacenados en esta estructura
-            de árbol, estos pueden ser organizados desde lo general (hacia la
-            raíz del árbol) a lo específico (hacia las ramas del árbol).
-            Consultas sobre un recurso específico buscarán automáticamente, en
+            de árbol,
+            estos pueden ser organizados desde lo general (hacia la
+            raíz del árbol) a lo específico
+            (hacia las ramas del árbol).
+            Consultas sobre un recurso específico buscarán
+            automáticamente, en
             la jerarquía del recurso, reglas asignadas a recursos anteriores a
             los que el recurso actual haga referencia, permitiendo la herencia
-            simple de reglas. Por ejemplo, si una regla por defecto se aplica a
-            cada edificio en una ciudad, uno simplemente podría asignar la regla
-            a la ciudad, en lugar de asignar la misma regla a cada edificio.
+            simple de reglas. Por
+            ejemplo, si una regla por defecto se aplica a
+            cada edificio en una ciudad, uno
+            simplemente podría asignar la regla
+            a la ciudad, en lugar de asignar la misma regla a
+            cada edificio.
             Algunos edificios pueden necesitar excepciones a la regla, sin
-            embargo, y esto es fácil de hacer en <classname>Zend_Acl</classname>
+            embargo, y
+            esto es fácil de hacer en
+            <classname>Zend_Acl</classname>
             asignando esta excepción a cada edificio que necesite una excepción
-            a la regla. Un recurso sólo puede heredar de un recurso padre,
-            aunque este recurso padre puede tener a la vez su propio recurso
-            padre, y así; sucesivamente.</para>
-       <para>
-            <classname>Zend_Acl</classname> también soporta privilegios sobre
-            recursos (ejemplo. "crear","leer","actualizar", "borrar"), y el
+            a la regla. Un
+            recurso sólo puede heredar de un recurso padre,
+            aunque este recurso padre puede tener a
+            la vez su propio recurso
+            padre, y así; sucesivamente.
+        </para>
+        <para>
+            <classname>Zend_Acl</classname>
+            también soporta privilegios sobre
+            recursos (ejemplo. "crear","leer","actualizar",
+            "borrar"), y el
             desarrollador puede asignar reglas que afecten o a todos los
-            privilegios o a privilegios específicos sobre un recurso.</para>
+            privilegios o
+            a privilegios específicos sobre un recurso.
+        </para>
     </sect2>
 
     <sect2 id="zend.acl.introduction.roles">
         <title>Acerca de las Reglas</title>
-       <para>Al igual que los recursos, la creación de un rol también es muy
-            simple. <classname>Zend_Acl</classname> proporciona
-                <classname>Zend_Acl_Role_Interface</classname> para facilitar a
+        <para>
+            Al igual que los recursos, la creación de un rol también es muy
+            simple.
+            <classname>Zend_Acl</classname>
+            proporciona
+            <classname>Zend_Acl_Role_Interface</classname>
+            para facilitar a
             los desarrolladores la creación de roles. Una clase solo necesita la
             implementación de su interfaz, la cual consiste en un método único,
-                <methodname>getRoleId()</methodname> , para que
-                <classname>Zend_Acl</classname> considere que el objeto es un
-            Rol. Adicionalmente, <classname>Zend_Acl_Role</classname> está
-            incluido con <classname>Zend_Acl</classname> como una implementación
+            <methodname>getRoleId()</methodname>
+            , para que
+            <classname>Zend_Acl</classname>
+            considere que el objeto es un
+            Rol. Adicionalmente,
+            <classname>Zend_Acl_Role</classname>
+            está
+            incluido con
+            <classname>Zend_Acl</classname>
+            como una implementación
             principal del rol para que los desarrolladores la extiendan hasta
-            donde lo deseen.</para>
-       <para>En <classname>Zend_Acl</classname>, un Rol puede heredar de otro
-            o más roles. Esto es para soportar herencia de reglas entre roles.
+            donde lo deseen.
+        </para>
+        <para>
+            En
+            <classname>Zend_Acl</classname>
+            , un Rol puede heredar de otro
+            o más roles. Esto es para soportar herencia de reglas
+            entre roles.
             Por ejemplo, un Rol de usuario, como "sally", puede estar bajo uno o
-            más roles padre, como "editor" y "administrador". El desarrollador
-            puede asignar reglas a "editor" y "administrador" por separado, y
-            "sally" puede heredar tales reglas de ambos, sin tener que asignar
-            reglas directamente a "sally".</para>
-       <para>Dado que la habilidad de herencia desde múltiples roles es muy
-            útil, múltiples herencias también introduce cierto grado de
-            complejidad. El siguiente ejemplo ilustra la condición de ambiguedad
-            y como <classname>Zend_Acl</classname> soluciona esto.</para>
+            más
+            roles padre, como "editor" y "administrador". El desarrollador
+            puede asignar reglas a
+            "editor" y "administrador" por separado, y
+            "sally" puede heredar tales reglas de ambos,
+            sin tener que asignar
+            reglas directamente a "sally".
+        </para>
+        <para>
+            Dado que la habilidad de herencia desde múltiples roles es muy
+            útil, múltiples herencias
+            también introduce cierto grado de
+            complejidad. El siguiente ejemplo ilustra la condición
+            de ambiguedad
+            y como
+            <classname>Zend_Acl</classname>
+            soluciona esto.
+        </para>
         <example id="zend.acl.introduction.roles.example.multiple_inheritance">
             <title>Herencia Múlltiple entre Roles</title>
-           <para>El siguiente código define tres roles principales -
-                "invitado", "miembro", y "admin" - de los cuales otros roles
-                pueden heredar. Entonces, un rol identificado como "unUsuario"
+            <para>
+                El siguiente código define tres roles principales -
+                "invitado", "miembro", y "admin"
+                - de los cuales otros roles
+                pueden heredar. Entonces, un rol identificado como
+                "unUsuario"
                 es colocado y hereda de los otros tres roles. El orden en el
-                cual estos roles aparecen en el array
-                    <varname>$parents</varname> es importante. Cuando es
-                necesario, <classname>Zend_Acl</classname> busca por reglas de
+                cual estos
+                roles aparecen en el array
+                <varname>$parents</varname>
+                es importante. Cuando es
+                necesario,
+                <classname>Zend_Acl</classname>
+                busca por reglas de
                 acceso definidas no solo para el rol solicitado (aquí,
                 "unUsuario"), sino también sobre los roles heredados (aquí,
-                "invitado", "miembro", y "admin"):</para>
+                "invitado", "miembro", y
+                "admin"):
+            </para>
             <programlisting language="php"><![CDATA[
 require_once 'Zend/Acl.php';
 $acl = new Zend_Acl();
@@ -124,48 +218,86 @@ $acl->allow('miembro', 'unRecurso');
 
 echo $acl->isAllowed('unUsuario', 'unRecurso') ? 'permitido' : 'denegado';
 ]]></programlisting>
-           <para>Ya que no hay reglas específicamente definidas para el rol
-                "unUsuario" y "unRecurso", <classname>Zend_Acl</classname> debe
+            <para>
+                Ya que no hay reglas específicamente definidas para el rol
+                "unUsuario" y "unRecurso",
+                <classname>Zend_Acl</classname>
+                debe
                 buscar por reglas que puedan estar definidas para roles
-                "unUsuario" hereda. Primero, el rol "admin" es visitado, y no
-                hay regla de acceso definida para éste. Luego, el rol "miembro"
-                es visitado, y <classname>Zend_Acl</classname> encuentra que
+                "unUsuario" hereda.
+                Primero, el rol "admin" es visitado, y no
+                hay regla de acceso definida para éste.
+                Luego, el rol "miembro"
+                es visitado, y
+                <classname>Zend_Acl</classname>
+                encuentra que
                 aquí hay una regla especificando que "miembro" tiene permiso
-                para acceder a "unRecurso".</para>
-           <para>Así, <classname>Zend_Acl</classname> va a seguir examinando
+                para
+                acceder a "unRecurso".
+            </para>
+            <para>
+                Así,
+                <classname>Zend_Acl</classname>
+                va a seguir examinando
                 las reglas definidas para otros roles padre, sin embargo,
                 encontraría que "invitado" tiene el acceso denegado a
-                "unRecurso". Este hecho introduce una ambigüedad debido a que
-                ahora "unUsuario" está tanto denegado como permitido para
+                "unRecurso". Este hecho
+                introduce una ambigüedad debido a que
+                ahora "unUsuario" está tanto denegado como
+                permitido para
                 acceder a "unRecurso", por la razón de tener un conflicto de
-                reglas heredadas de diferentes roles padre.</para>
-           <para>
-                <classname>Zend_Acl</classname> resuelve esta ambigüedad
-                completando la consulta cuando encuentra la primera regla que es
+                reglas
+                heredadas de diferentes roles padre.
+            </para>
+            <para>
+                <classname>Zend_Acl</classname>
+                resuelve esta ambigüedad
+                completando la consulta cuando encuentra la primera regla
+                que es
                 directamente aplicable a la consulta. En este caso, dado que el
-                rol "miembro" es examinado antes que el rol "invitado", el
-                código de ejemplo mostraría "permitido".</para>
+                rol "miembro"
+                es examinado antes que el rol "invitado", el
+                código de ejemplo mostraría "permitido".
+            </para>
         </example>
         <note>
-           <para>Cuando se especifican múltiples padres para un Rol, se debe
-                tener en cuenta que el último padre listado es el primero en ser
-                buscado por reglas aplicables para una solicitud de
+            <para>Cuando se especifican múltiples padres para un Rol, se debe
+                tener en cuenta que el
+                último padre listado es el primero en ser
+                buscado por reglas aplicables para una
+                solicitud de
                 autorización.</para>
         </note>
     </sect2>
 
     <sect2 id="zend.acl.introduction.creating">
-        <title>Creando las Listas de Control de Acceso
-            (<acronym>ACL</acronym>)</title>
-
-       <para>Una <acronym>ACL</acronym> puede representar cualquier grupo de
-            objetos físicos o virtuales que desee. Para propósitos de
-            demostración, sin embargo, crearemos un <acronym>ACL</acronym>
+        <title>
+            Creando las Listas de Control de Acceso
+            (
+            <acronym>ACL</acronym>
+            )
+        </title>
+
+        <para>
+            Una
+            <acronym>ACL</acronym>
+            puede representar cualquier grupo de
+            objetos físicos o virtuales que desee. Para
+            propósitos de
+            demostración, sin embargo, crearemos un
+            <acronym>ACL</acronym>
             básico para un Sistema de Administración de Contenido
-                (<acronym>CMS</acronym>) que mantendrá varias escalas de grupos
-            sobre una amplia variedad de áreas. Para crear un nuevo objeto
-                <acronym>ACL</acronym>, iniciamos la <acronym>ACL</acronym> sin
-            parámetros:</para>
+            (
+            <acronym>CMS</acronym>
+            ) que mantendrá varias escalas de grupos
+            sobre una amplia variedad de áreas. Para crear
+            un nuevo objeto
+            <acronym>ACL</acronym>
+            , iniciamos la
+            <acronym>ACL</acronym>
+            sin
+            parámetros:
+        </para>
 
         <programlisting language="php"><![CDATA[
 require_once 'Zend/Acl.php';
@@ -174,34 +306,48 @@ $acl = new Zend_Acl();
 ]]></programlisting>
 
         <note>
-           <para>Hasta que un desarrollador especifique una regla"permitido",
-                    <classname>Zend_Acl</classname> deniega el acceso a cada
-                privilegio sobre cada recurso para cada rol.</para>
+            <para>
+                Hasta que un desarrollador especifique una regla"permitido",
+                <classname>Zend_Acl</classname>
+                deniega el acceso a cada
+                privilegio sobre cada recurso para cada rol.
+            </para>
         </note>
     </sect2>
 
     <sect2 id="zend.acl.introduction.role_registry">
         <title>Registrando Roles</title>
 
-       <para>El Sistema de Administración de Contenido
-            (<acronym>CMS</acronym>) casi siempre necesita una jerarquía de
-            permisos para determinar la capacidad de identificación de sus
+        <para>
+            El Sistema de Administración de Contenido
+            (
+            <acronym>CMS</acronym>
+            ) casi siempre necesita una jerarquía de
+            permisos para determinar la capacidad de
+            identificación de sus
             usuarios. Puede haber un grupo de 'Invitados' para permitir acceso
             limitado para demostraciones, un grupo de 'Personal' para la mayoría
-            de usuarios del CMS quienes realizan la mayor parte de operaciones
-            del día a día, un grupo 'Editores' para las responsabilidades de
+            de usuarios del CMS
+            quienes realizan la mayor parte de operaciones
+            del día a día, un grupo 'Editores' para
+            las responsabilidades de
             publicación, revisión, archivo y eliminación de contenido, y
             finalmente un grupo 'Administradores' cuyas tareas pueden incluir
-            todas las de los otros grupos y también el mantenimiento de la
-            información delicada, manejo de usuarios, configuración de los datos
-            básicos y su respaldo/exportación. Este grupo de permisos pueden ser
+            todas las de los otros
+            grupos y también el mantenimiento de la
+            información delicada, manejo de usuarios,
+            configuración de los datos
+            básicos y su respaldo/exportación. Este grupo de permisos
+            pueden ser
             representados en un registro de roles, permitiendo a cada grupo
-            heredar los privilegios de los grupos 'padre', al igual que
-            proporcionando distintos privilegios solo para su grupo individual.
-            Los permisos pueden ser expresados como:</para>
-
-        <table
-            id="zend.acl.introduction.role_registry.table.example_cms_access_controls">
+            heredar los
+            privilegios de los grupos 'padre', al igual que
+            proporcionando distintos privilegios solo
+            para su grupo individual.
+            Los permisos pueden ser expresados como:
+        </para>
+
+        <table id="zend.acl.introduction.role_registry.table.example_cms_access_controls">
             <title>Controles de Acceso para un CMS de ejemplo</title>
             <tgroup cols="3">
                 <thead>
@@ -236,11 +382,17 @@ $acl = new Zend_Acl();
             </tgroup>
         </table>
 
-       <para>Para este ejemplo, se usa <classname>Zend_Acl_Role</classname> ,
+        <para>
+            Para este ejemplo, se usa
+            <classname>Zend_Acl_Role</classname>
+            ,
             pero cualquier objeto que implemente
-                <classname>Zend_Acl_Role_Interface</classname> es admisible.
+            <classname>Zend_Acl_Role_Interface</classname>
+            es admisible.
             Estos grupos pueden ser agregados al registro de roles de la
-            siguiente manera:</para>
+            siguiente
+            manera:
+        </para>
 
         <programlisting language="php"><![CDATA[
 require_once 'Zend/Acl.php';
@@ -273,19 +425,29 @@ $acl->addRole(new Zend_Acl_Role('administrador'));
     <sect2 id="zend.acl.introduction.defining">
         <title>Definiendo Controles de Acceso</title>
 
-       <para>Ahora que la <acronym>ACL</acronym> contiene los roles
+        <para>
+            Ahora que la
+            <acronym>ACL</acronym>
+            contiene los roles
             relevantes, se pueden establecer reglas que definan cómo los roles
             pueden acceder a los recursos. Tenga en cuenta que no definiremos
-            ningún recurso en particular para este ejemplo, el cual está
-            simplificado para ilustrar que las reglas se aplican a todos los
-            recursos. <classname>Zend_Acl</classname> proporciona una forma
+            ningún recurso en
+            particular para este ejemplo, el cual está
+            simplificado para ilustrar que las reglas se
+            aplican a todos los
+            recursos.
+            <classname>Zend_Acl</classname>
+            proporciona una forma
             práctica por la cual las reglas solo necesitan ser asignadas de lo
             general a lo especifico, minimizando el número de reglas necesarias,
-            porque los recursos y roles heredan reglas que están definidas en
-            sus padres.</para>
-
-       <para>Consecuentemente, podemos definir un grupo razonablemente
-            complejo de reglas con un mínimo de código. Para aplicar estos
+            porque los recursos
+            y roles heredan reglas que están definidas en
+            sus padres.
+        </para>
+
+        <para>Consecuentemente, podemos definir un grupo razonablemente
+            complejo de reglas con un
+            mínimo de código. Para aplicar estos
             permisos básicos como están definidos arriba:</para>
 
         <programlisting language="php"><![CDATA[
@@ -319,20 +481,32 @@ $acl->allow('editor', null, array('publicar', 'archivar', 'eliminar'));
 $acl->allow('administrador');
 ]]></programlisting>
 
-       <para>El valor <constant>NULL</constant> en las llamadas de
-                <methodname>allow()</methodname> es usado para indicar que las
-            reglas de permiso se aplican a todos los recursos.</para>
+        <para>
+            El valor
+            <constant>NULL</constant>
+            en las llamadas de
+            <methodname>allow()</methodname>
+            es usado para indicar que las
+            reglas de permiso se aplican a todos los recursos.
+        </para>
 
     </sect2>
 
     <sect2 id="zend.acl.introduction.querying">
         <title>Consultando la ACL</title>
 
-       <para>Ahora tenemos una <acronym>ACL</acronym> flexible que puede ser
-            usada para determinar qué solicitantes tienen permisos para realizar
+        <para>
+            Ahora tenemos una
+            <acronym>ACL</acronym>
+            flexible que puede ser
+            usada para determinar qué solicitantes tienen permisos para
+            realizar
             funciones a través de la aplicación web. Ejecutar consultas es la
-            forma más simple de usar el método
-                <methodname>isAllowed()</methodname> :</para>
+            forma más
+            simple de usar el método
+            <methodname>isAllowed()</methodname>
+            :
+        </para>
 
         <programlisting language="php"><![CDATA[
 echo $acl->isAllowed('invitado', null, 'ver') ?