corrected examples

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3961 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0045.xml

@@ -745,7 +745,7 @@
         </tr>
       </table>
       <p>* A moderator MUST NOT be able to revoke moderator privileges from an occupant who is equal to or above the moderator in the hierarchy of affiliations.</p>
-      <p class='box'>Note: Certain roles are typically implicit in certain affiliations. For example, an admin or owner is automatically a moderator, so if an occupant is granted an affiliation of admin then the occupant will by that fact be granted a role of moderator; similarly, when an occupant is granted an affiliation of member in a moderated room, the occupant automatically has a role of participant. However, the loss of the admin affiliation does not necessarily mean that the occupant no longer has a role of moderator (since a "mere" participant can be a moderator). Therefore, the role that is gained when an occupant is granted a certain affiliation is stable, whereas the role that is lost when an occupant loses a certain affilitation is not hardcoded and is left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both the admin/owner affiliation and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change by including both the 'role' attribute and the 'affiliation' attribute.</p>
+      <p class='box'>Note: Certain roles are typically implicit in certain affiliations. For example, an admin or owner is automatically a moderator, so if an occupant is granted an affiliation of admin then the occupant will by that fact be granted a role of moderator; similarly, when an occupant is granted an affiliation of member in a moderated room, the occupant automatically has a role of participant. However, the loss of the admin affiliation does not necessarily mean that the occupant no longer has a role of moderator (since a "mere" occupant can be a moderator). Therefore, the role that is gained when an occupant is granted a certain affiliation is stable, whereas the role that is lost when an occupant loses a certain affilitation is not hardcoded and is left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both the admin/owner affiliation and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change by including both the 'role' attribute and the 'affiliation' attribute.</p>
     </section3>
   </section2>
   <section2 topic='Affiliations' anchor='affil'>
@@ -1230,7 +1230,7 @@
       <p>Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p>
     </section3>
     <section3 topic='Presence Broadcast' anchor='enter-pres'>
-      <p>If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate:</p>
+      <p>If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in a single &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate. <note>The &PRESENCE; element MUST NOT include more than once instance of the &X; qualified by the 'http://jabber.org/protocol/muc#user' namespace.</note></p>
       <example caption='Service Sends Presence from Existing Occupants to New Occupant'><![CDATA[
 <presence
     from='darkcave@chat.shakespeare.lit/firstwitch'
@@ -1249,7 +1249,7 @@
 </presence>
       ]]></example>
       <p>In this example, the user from the previous example has entered the room, by which time two other people had already entered the room: a user with a room nickname of "firstwitch" (who is a room owner) and a user with a room nickname of "secondwitch" (who is a room admin).</p>
-      <p>The service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant):</p>
+      <p>The service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant).</p>
       <example caption="Service Sends New Occupant's Presence to All Occupants"><![CDATA[
 <presence
     from='darkcave@chat.shakespeare.lit/thirdwitch'
@@ -2273,11 +2273,11 @@
 </iq>
     ]]></example>
     <p>If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with <cite>XEP-0030</cite>).</p>
-    <p>Even if a user has registered one room nickname, the service SHOULD allow the user to specify a different nickname on entering the room (e.g., in order to join from different client resources), although the service MAY choose to "lock down" nicknames and therefore deny entry to the user, including a &notacceptable; error. The service MUST NOT return an error to the user if his or her client sends the foregoing request after having already joined the room, but instead SHOULD reply as described above.</p>
+    <p>Even if a user has registered one room nickname, the service SHOULD allow the user to specify a different nickname on entering the room (e.g., in order to join from different client resources), although the service MAY choose to "lock down" nicknames and therefore deny entry to the user, including a &notacceptable; error. The service MUST NOT return an error to the user if his or her client sends the foregoing request after having already joined the room, but instead SHOULD reply as previously described.</p>
     <p>If another user attempts to join the room with a nickname reserved by the first user, the service MUST deny entry to the second user and return a &conflict; error as previously described.</p>
   </section2>
   <section2 topic='Requesting Voice' anchor='requestvoice'>
-    <p>It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where data form contains only a 'muc#role' field with a value of "participant".</p>
+    <p>It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where the data form contains only a 'muc#role' field with a value of "participant".</p>
     <example caption='Occupant Requests Voice'><![CDATA[
 <message from='hag66@shakespeare.lit/pda'
          to='darkcave@chat.shakespeare.lit'>
@@ -4314,7 +4314,7 @@
   <section2 topic='Modifying the Admin List' anchor='modifyadmin'>
     <p>A room owner may want to modify the admin list. To do so, the owner first requests the admin list by querying the room for all users with an affiliation of 'admin'.</p>
     <example caption='Owner Requests Admin List'><![CDATA[
-<iq from='bard@shakespeare.lit/desktopaffiliation
+<iq from='bard@shakespeare.lit/desktop'
     id='admin3'
     to='darkcave@chat.shakespeare.lit'
     type='get'>