PDF fixes

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

xep-0037.xml

@@ -1,8 +1,9 @@
-<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
+<?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
-  <!ENTITY % ents SYSTEM "xep.ent">
+  <!ENTITY % ents SYSTEM 'xep.ent'>
 %ents;
 ]>
+<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 <xep>
 <header>
   <title>DSPS - Data Stream Proxy Service</title>

xep-0048.xml

@@ -283,7 +283,7 @@
     <p>No action by the &REGISTRAR; is required, since the 'storage:bookmarks' namespace is already included in the protocol namespaces registry (see &NAMESPACES;).</p>
 </section1>
 
-<section1 topic='XML Schema' anchor='registrar'>
+<section1 topic='XML Schema' anchor='schema'>
   <code><![CDATA[
 <?xml version='1.0' encoding='UTF-8'?>
 

xep-0054.xml

@@ -306,7 +306,7 @@ xmpp:romeo@montague.net?vcard
     ]]></code>
   </section2>
 </section1>
-<section1 topic='Implementation Notes' anchor='usecases'>
+<section1 topic='Implementation Notes' anchor='impl'>
   <p>Note the following:</p>
   <ul>
     <li>The correct capitalization of the wrapper element is &lt;vCard/&gt; (and XML element names are case-sensitive).</li>

xep-0060.xml

@@ -4099,7 +4099,7 @@ And by opposing end them?
     ]]></example>
     <p>The service MUST check the "pubsub#allow" field to see if the subscription should be allowed or denied. If the owner cancels the Data Form, then the subscription request MUST remain in the pending state.</p>
   </section2>
-  <section2 topic='Process Pending Subscription Requests' anchor='owner-subreq'>
+  <section2 topic='Process Pending Subscription Requests' anchor='owner-subreq-process'>
     <p>A node owner may want to request all of the pending subscription requests for all of their nodes at a service. It is OPTIONAL for a service to implement this feature.</p>
     <p>This feature MUST be implemented using the &xep0050; protocol, where the command name ('node' attribute of the command element) MUST have a value of "http://jabber.org/protocol/pubsub#get-pending".</p>
     <section3 topic='Request' anchor='owner-subreq-request'>

xep-0124.xml

@@ -387,7 +387,7 @@ Content-Length: 88
       xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
     <p>The connection manager MUST wait and respond in the same way as it does after receiving stanzas from the client.</p>
   </section1>
-  <section1 topic='Acknowledgements' anchor='ack'>
+  <section1 topic='Acknowledgements' anchor='acks'>
     <section2 topic='Request Acknowledgements' anchor='ack-request'>
       <p>When responding to a request that it has been holding, if the connection manager finds it has already received another request with a higher 'rid' attribute (typically while it was holding the first request), then it MAY acknowledge the reception to the client. The connection manager MAY set the 'ack' attribute of any response to the value of the highest 'rid' attribute it has received in the case where it has also received all requests with lower 'rid' values.</p>
       <example caption="Response with request acknowledgement">

xep-0136.xml

@@ -233,7 +233,7 @@
     </section3>
     <section3 topic='Item Element' anchor='pref-syntax-item'>
       <p>The &lt;item/&gt; element specifies the settings for both the OTR Mode and Save Mode with regard to a particular entity. The element MUST be empty and MUST include a 'jid' attribute, an 'otr' attribute, and a 'save' attribute. The element MAY include an 'expire' attribute.</p>
-      <section4 topic='expire Attribute' anchor='pref-syntax-default-expire'>
+      <section4 topic='expire Attribute' anchor='pref-syntax-expire'>
         <p>If the 'save' attribute is <em>not</em> set to 'false' then is RECOMMENDED to also include an 'expire' attribute, which indicates how many seconds after messages are archived that the server SHOULD delete them.</p>
       </section4>
       <section4 topic='jid Attribute' anchor='pref-syntax-item-jid'>

xep-0198.xml

@@ -123,7 +123,7 @@ S: <stream:features>
   ]]></example>
 </section1>
 
-<section1 topic='Enabling a Stream Management Session' anchor='feature'>
+<section1 topic='Enabling a Stream Management Session' anchor='enable'>
   <p>To enable use of stream management, the client sends an &lt;enable/&gt; command to the server. If it wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false &BOOLEANNOTE;.</p>
   <example caption='Client enables stream management'><![CDATA[
 C: <enable xmlns='urn:xmpp:sm:0'/>

xep-0206.xml

@@ -306,7 +306,7 @@ Content-Length: 68
   ]]></example>
 </section1>
 
-<section1 topic='&recipient;' anchor='security'>
+<section1 topic='recipient-unavailable' anchor='recipient-unavailable'>
   <p>It is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform the XMPP server that the connection has died). In this case, the connection manager would return an error to the XMPP server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of <cite>RFC 3921</cite>:</p>
   <ol>
     <li>If the delivered stanza was &PRESENCE;, silently drop the stanza and do not return an error to the sender.</li>

xep-0209.xml

@@ -127,7 +127,7 @@
   <section2 topic='Removing a metacontact' anchor='removing'>
     Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact.
   </section2>
-  <section2 topic='Uniqueness of order within a metacontact' anchor='removing'>
+  <section2 topic='Uniqueness of order within a metacontact' anchor='uniqueness'>
 		<p>Although it is unavoidable that multiple contacts within a metacontact MAY have the same order (due to potentially unavailable information from other accounts), clients SHOULD NOT apply the same order to multiple members of the same metacontact where it is possible to avoid it. If multiple members of a metacontact have the same order, the behaviour is dependent upon the client; it MAY apply rules itself to determine which member to communicate with (based upon presence, recent activity or other methods) it MAY present the user with the option to sort the members such that the orders are again unique, or it MAY employ another appropriate action.</p>
 		<p>As the order attribute is optional, clients need a method for determining which member contact to use where the metacontact consists entirely of unordered members. When ordered and unordered members are present, unordered members SHOULD be considered to have the lowest order.</p>
 	</section2>

xep-0244.xml

@@ -262,7 +262,7 @@ if (function instanceof IoDataFunction) {
 		</table>
 	</section2>
 	
-	<section2 topic='Container Elements' anchor='trans'>
+	<section2 topic='Container Elements' anchor='container'>
 		<p>&lt;desc&gt; -- a textual description of the IO Data data container (xs:string).</p>
 		<p>&lt;in&gt; -- contains the input. Valid for Transaction Type 'input' and 'io-schemata-result' only. May contain any XML data (XML Schema, XML Document ...).</p>
 		<p>&lt;out&gt; -- contains the output. Valid for Transaction Type 'output' and 'io-schemata-result' only. May contain any XML data (XML Schema, XML Document ...).</p>