On Mittwoch, 29. Juli 2020 00:29:11 CEST Tedd Sterr wrote: > 4a ii) PR #971 (XEP-0004: Clarify field type omission for 'submit' and > 'result' form field types) - https://github.com/xsf/xeps/pull/972 Jonas: > [on-list] > Zash: [on-list] > Daniel: [on-list] > Georg: [pending] > Dave: [pending]
Let me break this change down using the word diff (attached: ab.wdiff, pipe it through colordiff(1) for best viewing). Before: - type="form": @type SHOULD, absent implies "text-single" - type="submit": @type MAY, absent assumes available context(*) - type="error", type="result": @type MAY, absent undefined After: - type="form": @type SHOULD, absent implies "text-single" - type="submit", type="result": @type MAY, absent assumes available context(*) - type="error": undefined (*): It is assumed that the recipient of the form has enough context to infer the @type value. Bad design IMO, but we’re stuck with that. So while the PR reduces the amount of text, it introduces undefined behaviour for @type="error", which I don’t endorse. I am -1 on the PR as-is, but I would change to +1 if the type="error" was included in the added text either implicitly or explicitly. Example: > 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"). For data forms of other types, 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. (also attached as patch on top of the proposed change. An alternative variant where the types are listed explicitly would also be OK by me and you can assume a +1 from my side.) In that case, we’d have: - type="form": @type SHOULD, absent implies "text-single" - type="submit", type="result", type="error": @type MAY, absent assumes available context(*) This also changes defined behaviour, though the previous wording was rather unclear on that intent (see "Before") section. If we do not want to change that, I suppose we should not accept #971 with or without my patch. I do not think this particular change may pose any issues (given that absent field types in @type="error" and @type="result" were undefined before). kind regards, Jonas
<p>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.-] {+"text-single").+} For data forms of
type [-"submit",-] {+"submit" and "result",+} 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.</p>
diff --git a/xep-0004.xml b/xep-0004.xml
index 840e935..799f187 100644
--- a/xep-0004.xml
+++ b/xep-0004.xml
@@ -223,7 +223,7 @@
<di><dt><value/></dt><dd>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.</dd></di>
<di><dt><option/></dt><dd>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.</dd></di>
</dl>
- <p>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"). For data forms of type "submit" and "result", 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.</p>
+ <p>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"). For data forms of other types, 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.</p>
<p>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.</p>
</section2>
<section2 topic='Field Types' anchor='protocol-fieldtypes'>
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
