From db9750991dc6e1e3cf93a4c8b7072063d1908816 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 9 Oct 2008 04:17:51 +0000 Subject: [PATCH] typos git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2354 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0059.xml | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/xep-0059.xml b/xep-0059.xml index 97a15e7df..55b0ea67c 100644 --- a/xep-0059.xml +++ b/xep-0059.xml @@ -137,7 +137,7 @@

In order to limit the number of items of a result set to be returned, the requesting entity specifies a request type of "set" and the maximum size of the desired subset (via the XML character data of the <max/> element):

+ Pete @@ -180,7 +180,7 @@

Note: If a responding entity implements dynamic result sets then receiving entities paging through the complete result set should be aware that it may not correspond to the result set as it existed at any one point in time.

The request for the first page is the same as when Limiting the Number of Items:

+ Pete @@ -219,7 +219,7 @@ ]]>

The requesting entity can then ask for the next page in the result set by including in its request the UID of the last item from the previous page (encapsulated in an <after/> element), along with the maximum number of items to return. Note: If no <after/> element is specified, then the UID defaults to "before the first item in the result set" (i.e., effectively an index of negative one).

+ Pete @@ -269,7 +269,7 @@

The requesting entity MAY ask for the previous page in a result set by including in its request the UID of the first item from the page that has already been received (encapsulated in a <before/> element), along with the maximum number of items to return.

+ Pete @@ -330,7 +330,7 @@

The requesting entity MAY ask for the last page in a result set by including in its request an empty <before/> element, and the maximum number of items to return.

+ Pete @@ -346,7 +346,7 @@

Only if the UID before the start (or after the end) of a desired result set page is not known, then the requesting entity MAY request the page that starts at a particular index within the result set. It does that by including in its request the index of the first item to be returned (encapsulated in an <index/> element), as well as the maximum number of items to return. Note: For reasons mentioned in Paging Forwards Through a Result Set requesting entities SHOULD, where possible, specify pages using a UID instead of an index.

Note: If the responding entity omitted the <count/> element from previous responses for this result set, then the requesting entity SHOULD assume that the responding entity does not support page retrieval by index for this result set (see error below).

+ Pete @@ -401,7 +401,7 @@

In order to get the item count of a result set without retrieving the items themselves, the requesting entity simply specifies zero for the maximum size of the result set page:

+ Pete @@ -427,7 +427,7 @@

The foregoing examples show the use of result set management in the context of Jabber Search. In the following examples we show the use of this protocol in the context of Service Discovery. XEP-0136 ("Message Archiving") includes more examples. A future version of this document may also include examples from Publish-Subscribe and other XMPP protocol extensions.

+ 20 @@ -467,7 +467,7 @@ ]]> + 20 @@ -477,7 +477,7 @@ ]]> - +

In order for a requesting entity to determine if a responding entity supports result set management, it SHOULD send a Service Discovery information request to the responding entity:

- ... - ... ]]>