XEP-0366: Fix whitespace and DTD issues

xep-0366.xml

@@ -98,18 +98,24 @@
 
 <section1 topic='Glossary' anchor='glossary'>
   <dl>
+    <di>
       <dt>Aggregate Token</dt>
       <dd>
         A hash which represents the state of a list of entities, and changes if
         any of the entities change.
       </dd>
+    </di>
+    <di>
       <dt>Versioned Entity</dt>
       <dd>Any object which may be versioned (eg. rooms, users).</dd>
+    </di>
+    <di>
       <dt>Version Token</dt>
       <dd>
         A short, case sensitive string which represents an entity and changes if
         that entity changes.
       </dd>
+    </di>
   </dl>
 </section1>
 
@@ -196,7 +202,7 @@
     <profile xmlns='urn:xmpp:entityver:profile:roster:0'/>
   </ver>
 </stream:features>
-  ]]></example>
+]]></example>
   <p>
     The entity versioning stream feature is merely informative and therefore
     is never mandatory-to-negotiate.
@@ -208,6 +214,7 @@
     the responding entity as described in the relavant specifications. Eg. a
     response from a server that supports roster versioning for the requesting
     entity might look like the following:
+  </p>
   <example caption="Service discovery information response"><![CDATA[
 <iq from='shakespeare.lit'
     id='ku6e51v3'
@@ -217,9 +224,7 @@
     <feature var='urn:xmpp:entityver:0'/>
     <feature var='urn:xmpp:entityver:profile:roster:0'/>
   </query>
-</iq>
+</iq>]]></example>
-    ]]></example>
-  </p>
 </section1>
 
 <section1 topic='Entity Sync' anchor='entity_sync'>
@@ -251,6 +256,7 @@
     </p>
     <p>
       For example, a versioned roster request might look like this:
+    </p>
     <example caption="Roster Request"><![CDATA[
 <!-- Client -->
 <iq from='romeo@montague.lit/home' id='56' to='romeo@montague.lit' type='get'>
@@ -271,15 +277,14 @@
       <version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version>
     </item>
   </query>
-</iq>
+</iq>]]></example>
-        ]]></example>
-    </p>
     <p>
       Note that in this case there may be three roster items total (and the
       client only knows about two of them), or there may be two total roster
       items and the server is informing the client about a change to
       "bill@shakespeare.lit". Version tokens MUST also be present in roster
       pushes:
+    </p>
     <example caption="Roster Push"><![CDATA[
 <iq from='romeo@montague.lit' id='ah382g678jka7' to='romeo@montague.lit/home' type='set'>
   <query xmlns='jabber:iq:roster' ver='ver34'>
@@ -288,8 +293,7 @@
     </item>
   </query>
 </iq>
-      ]]></example>
+]]></example>
-    </p>
   </section2>
   <section2 topic='Cache Invalidation' anchor='deletes'>
     <p>
@@ -300,6 +304,7 @@
       the client receives such an empty version node it SHOULD purge the entity
       from its cache. For example, the following would remove the roster item
       'bill@shakespeare.lit' from the cache:
+    </p>
     <example caption="Cache invalidation"><![CDATA[
 <iq from='romeo@montague.lit' id='56' to='romeo@montague.lit/home' type='result>
   <query xmlns='jabber:iq:roster'>
@@ -307,9 +312,7 @@
       <version xmlns='urn:xmpp:entityver:0'/>
     </item>
   </query>
-</iq>
+</iq>]]></example>
-    ]]></example>
-    </p>
     <p>
       Roster pushes that indicate a deleted item MUST also remove the version
       from the cache (and need not contain an empty &lt;version/&gt; element).
@@ -338,6 +341,7 @@
       no mechanism is specified, this is done by adding a boolean "full_list"
       attribute to the request, eg. a roster request for a partial list looks
       like:
+    </p>
     <example caption="Roster Request"><![CDATA[
 <!-- Client -->
 <iq from='romeo@montague.lit/home'
@@ -361,9 +365,7 @@
       <version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version>
     </item>
   </query>
-</iq>
+</iq>]]></example>
-    ]]></example>
-    </p>
     <p>
       When making a request for a partial list, clients do not need to send up
       every entity in their cache. Instead they MAY send up just those entities
@@ -389,6 +391,7 @@
       namespace and MUST have a 'profile' attribute set to the namespace for
       which the search is being performed. For instance, searching the roster
       looks like the following:
+    </p>
     <example caption="Roster search"><![CDATA[
 <!-- Client -->
 <iq from='romeo@montague.lit/home'
@@ -407,9 +410,7 @@
       <version xmlns='urn:xmpp:entityver:0'>4YAZ7Y38</version>
     </item>
   </query>
-</iq>
+</iq>]]></example>
-    ]]></example>
-    </p>
     <p>
       Search results SHOULD be added to the given list's cache. In this way,
       the full list does not need to be known.
@@ -436,13 +437,13 @@
     </p>
     <example caption="Aggregate token list"><![CDATA[
 anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
-    ]]></example>
+]]></example>
     <p>
       Which results in the aggregate token:
     </p>
     <example caption="Aggregate token"><![CDATA[
 0514fc90e6c7981b06bbb2173bb8ef03
-    ]]></example>
+]]></example>
     <p>
       The actual request is an IQ sent to the server, or entity handling the
       versioned list which contains a query that specifies the namespace of the
@@ -462,7 +463,7 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
     0514fc90e6c7981b06bbb2173bb8ef03
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>
       Because aggregate tokens are OPTIONAL to implement, clients MUST fall
       back to making a normal list request if any error is returned in response
@@ -514,17 +515,17 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
     lists in response to queries. For the case of rosters one or more of the
     following may be returned to the requesting entity during the initial
     roster sync:
+  </p>
   <ul>
     <li>
-        Users that are grouped with the requester in some way. Eg. for a
+      Users that are grouped with the requester in some way.
-        company with a large shared roster which places the requesting client
+      Eg. for a company with a large shared roster which places the requesting
-        in the "Marketing Department" group, the server may wish to return
+      client in the "Marketing Department" group, the server may wish to return
       roster items that also share that group.
     </li>
     <li>Users whom the requester has contacted recently or frequently.</li>
     <li>Users that should always be returned as part of server policy.</li>
   </ul>
-  </p>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>
@@ -579,8 +580,7 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
     The document in which the EV profile for the list is specified (may be the
     same as <listdev/>).
   </doc>
-</profile>
+</profile>]]></code>
-    ]]></code>
   </section2>
   <section2 topic='Entity Versioning Profiles' anchor='registrar-evprofile'>
     <p>This specification defines the following entity versioning profile:</p>
@@ -591,20 +591,19 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
       Upon advancement of this specification from a status of Experimental to a
       status of Draft, the &REGISTRAR; shall add the following definition to
       the entity versioning profiles registry, as described in this document:
+    </p>
     <code><![CDATA[
 <profile>
   <name>Roster entity versioning</name>
   <desc>Allows versioning of entities in an XMPP roster.</desc>
   <listdef>RFC 6121</listdef>
   <doc>TODO: Insert this document once it is assigned a number</doc>
-</profile>
+</profile>]]></code>
-      ]]></code>
-    </p>
   </section2>
 </section1>
 
 <section1 topic='XML Schema' anchor='schema'>
-TODO
+  <p>TODO</p>
 </section1>
 
 <section1 topic='Acknowledgements' anchor='ack'>