From f35b0ace4110cd7771fbbdd80750e8e94ac38922 Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Fri, 17 Jul 2020 15:43:20 +0200 Subject: [PATCH] XEP-0004: Clarify field type omission for 'submit' and 'result' form field types The specification was a bit involved about that topic. Hopefully this reformatting text improves the readability. This commit is based on a different patch by Florian Schmaus and hopefully further improves clarity by spelling out all cases clearly in a list, as well as more thoroughly defining corner cases. --- xep-0004.xml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xep-0004.xml b/xep-0004.xml index 795d3b7b..ed4514c6 100644 --- a/xep-0004.xml +++ b/xep-0004.xml @@ -223,7 +223,12 @@
<value/>
The XML character data of this element defines the default value for the field (according to the form-processing entity) in a data form of type "form", the data provided by a form-submitting entity in a data form of type "submit", or a data result in a data form of type "result". In data forms of type "form", if the form-processing entity provides a default value via the <value/> element, then the form-submitting entity SHOULD NOT attempt to enforce a different default value (although it MAY do so to respect user preferences or anticipate expected user input). Fields of type list-multi, jid-multi, text-multi, and hidden MAY contain more than one <value/> element; all other field types MUST NOT contain more than one <value/> element.
<option/>
One of the options in a field of type "list-single" or "list-multi". The XML character of the <value/> child defines the option value, and the 'label' attribute defines a human-readable name for the option. The <option/> element MUST contain one and only one <value/> child. If the field is not of type "list-single" or "list-multi", it MUST NOT contain an <option/> element.
 -

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. For data forms of type "submit", inclusion of the 'type' attribute is OPTIONAL, since the form-processing entity is assumed to understand the data types associated with forms that it processes.

+

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.

+

The 'type' attribute defines the data "type" of the field data. The following rules apply for that attribute:

+

If fields are presented in a user interface (e.g., as items in a questionnaire or form result), the order of the field elements in the XML SHOULD determine the order of items presented to the user.