[Standards] Council Minutes 2020-07-22

Jonas Schäfer jonas at wielicki.name
Wed Aug 5 14:04:11 UTC 2020


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
-------------- next part --------------
     <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> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xep-0004-fill-ub-gaps.patch
Type: text/x-patch
Size: 3183 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200805/f3b4b4ce/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200805/f3b4b4ce/attachment.sig>


More information about the Standards mailing list