[Standards-JIG] JEP-0004 Data Forms issues

Peter Saint-Andre stpeter at jabber.org
Fri Dec 30 17:16:51 UTC 2005


I've provisionally updated JEP-0004 to incorporate these errata:

http://www.jabber.org/jeps/tmp/jep-0004-2.7.html

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0004/jep-0004.xml?r1=1.50&r2=1.51

Do the changes reflect the list consensus? If so, I will put this item 
on the agenda for the next Council meeting.

Peter

Peter Saint-Andre wrote:
> 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
> 
-------------- 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/20051230/28562254/attachment.bin>


More information about the Standards mailing list