From c75b4bd7082ade19e11c66e5b5fe9bc9df68bb42 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 10 Jul 2007 21:04:17 +0000 Subject: [PATCH] 2.9pre1 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1031 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0004.xml | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/xep-0004.xml b/xep-0004.xml index c23571a3..23b2e2ba 100644 --- a/xep-0004.xml +++ b/xep-0004.xml @@ -27,6 +27,12 @@ &jer; &temas; &stpeter; + + 2.9pre1 + in progress, last updated 2007-07-10 + psa +

Clarified the definition and handling of the list-multi and list-single field types.

+
2.8 2007-05-21 @@ -208,7 +214,7 @@

If the <field/> element type is anything other than "fixed" (see below), it MUST possess a 'var' attribute that uniquely identifies the field in the context of the form (if it is "fixed", it MAY possess a 'var' attribute). The <field/> element MAY possess a 'label' attribute that defines a human-readable name for the field. For data forms of type "form", each <field/> element SHOULD possess a 'type' attribute that defines the data "type" of the field data (if no 'type' is specified, the default is "text-single"); fields provided in the context of other forms types MAY possess a 'type' attribute as well.

@@ -234,28 +240,28 @@ The field is not shown to the form-submitting entity, but instead is returned with the form. - jid-multi * - The field enables an entity to gather or provide multiple Jabber IDs. + jid-multi + The field enables an entity to gather or provide multiple Jabber IDs. * - jid-single * - The field enables an entity to gather or provide a single Jabber ID. + jid-single + The field enables an entity to gather or provide a single Jabber ID. * list-multi - The field enables an entity to gather or provide one or more options from among many. + The field enables an entity to gather or provide one or more options from among many. A form-submitting entity chooses one or more items from among the options presented by the form-processing entity and MUST NOT insert new options. ** list-single - The field enables an entity to gather or provide one option from among many. + The field enables an entity to gather or provide one option from among many. A form-submitting entity chooses one item from among the options presented by the form-processing entity and MUST NOT insert new options. ** - text-multi ** - The field enables an entity to gather or provide multiple lines of text. + text-multi + The field enables an entity to gather or provide multiple lines of text. *** text-private - The field enables an entity to gather or provide a single line or word of text, which shall be obscured in an interface (e.g., *****). + The field enables an entity to gather or provide a single line or word of text, which shall be obscured in an interface (e.g., with multiple instances of the asterisk character). text-single @@ -263,7 +269,8 @@

* Note: Data provided for fields of type "jid-single" or "jid-multi" MUST contain one or more valid Jabber IDs, where validity is determined by the addressing rules defined in XMPP Core (see the Data Validation section below).

-

** Note: Data provided for fields of type "text-multi" SHOULD NOT contain any newlines (the \n and \r characters). Instead, the application SHOULD split the data into multiple strings (based on the newlines inserted by the platform), then specify each string as the XML character data of a distinct <value/> element. Similarly, an application that receives multiple <value/> elements for a field of type "text-multi" SHOULD merge the XML character data of the value elements into one text block for presentation to a user, with each string separated by a newline character as appropriate for that platform.

+

** Note: The <option/> elements in list-multi and list-single fields MUST be unique, where uniqueness is determined by the value of the 'label' attribute and the XML character data of the <value/> element (i.e., both must be unique).

+

*** Note: Data provided for fields of type "text-multi" SHOULD NOT contain any newlines (the \n and \r characters). Instead, the application SHOULD split the data into multiple strings (based on the newlines inserted by the platform), then specify each string as the XML character data of a distinct <value/> element. Similarly, an application that receives multiple <value/> elements for a field of type "text-multi" SHOULD merge the XML character data of the value elements into one text block for presentation to a user, with each string separated by a newline character as appropriate for that platform.

In some contexts (e.g., the results of a search request), it may be necessary to communicate multiple items. Therefore, a data form of type "result" MAY contain two child elements not described in the basic syntax above: one <reported/> element followed by zero or more <item/> elements. The syntax is as follows: