[Standards-JIG] JEP-0004 Data Forms issues

Peter Saint-Andre stpeter at jabber.org
Thu Dec 29 23:50:32 UTC 2005


Ian Paterson wrote:
> Peter wrote:
>> I think that needs to be corrected to:
>>
>> * <value/> -- The XML character data of this element defines 
>> the default value for the field, the data provided by an 
>> entity that has completed the form, or a data result. In
>> data forms of type "form", an entity SHOULD NOT attempt to
>> enforce a default value if it is not provided via the
>> <value/> element.
> 
> IMHO that last sentence should be:
> "In data forms of type 'form', it is RECOMMENDED that an entity does not
> enforce a *different* default value if one *is* provided via a <value/>
> element."

How about this?

In data forms of type "form", if the form-processing entity provided a 
default value via the <value/> element, the form-submitting entity 
SHOULD NOT attempt to enforce a default value other than that provided 
by the form-processing entity.

>> If the field type is "list-multi", the <field/> 
>> element MAY contain more than one <value/> child.
> 
> Yes. Only four of the field types (list-multi, jid-multi, text-multi,
> hidden) should be allowed to contain more than one <value/> child. To
> make this clear to implementors, perhaps these could be specified in
> "Table 2: Field Types"?

Yes.

> IMHO, type 'hidden' should be allowed multiple values since that makes
> it trivial for client developers to simplify a form before presenting it
> to the user - by changing the type of fields to 'hidden'. I also know of
> one server implementation that includes multiple values in hidden form
> fields.

Yes, I think that's fine.

>> * <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.
> 
> Yes.
> 
> It would also make things clearer for implementors if the field with
> type 'list-multi' in Example 2 "Service Returns Bot Creation Form" were
> to include two default values (as per Joe's example):
> 
> <field type='list-multi'
>        label='What features will the bot support?'
>        var='features'>
>   <option label='Contests'><value>contests</value></option>
>   <option label='News'><value>news</value></option>
>   <option label='Polls'><value>polls</value></option>
>   <option label='Reminders'><value>reminders</value></option>
>   <option label='Search'><value>search</value></option>
>   <value>news</value>
>   <value>search</value>
> </field>

Agreed.

> One more informative suggestion: Might it be helpful to add an explicit
> note to state that, "fields of type 'jid-single' and 'jid-multi' MUST
> NOT contain <option/> elements"? (That would eliminate any potential
> doubts that might occur due to the fact that the UIs of the 'jid' and
> 'list' fields are the same.)

In fact only fields of type list-single and list-multi may contain the 
<option/> element, so it's probably best to say that.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20051229/31f79940/attachment.bin>


More information about the Standards mailing list