[Standards-JIG] JEP-0004 Data Forms issues

Peter Saint-Andre stpeter at jabber.org
Wed Dec 28 17:59:57 UTC 2005


Joe Hildebrand wrote:
> On Dec 26, 2005, at 1:23 PM, Ian Paterson wrote:
>> 1. It states that: "The <option/> element MAY contain more than one
>> <value/> child if the field type is 'list-multi'."

Among other things, that violates the schema.

Version 2.0 of JEP-0004 had the following note:

"The list-multi is the only field that allows you to set multiple 
<value/> tags.  All other field types should ignore any additional 
values and just take the first one listed."

So in a form of type "form" you could see something like this (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>
</field>

And in a form of type "submit" you could see something like this:

<field type='list-multi var='features'>
   <value>polls</value>
   <value>search</value>
</field>

So I would agree with Joe that the current text is in error:

* <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.
* <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 MAY contain more than one <value/> child 
if the field type is "list-multi".

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. If the field type is "list-multi", the <field/> 
element MAY contain more than one <value/> child.
* <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.

>> 2. It states that: "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."
>> What is the reason for this restriction? There are typical instances
>> where allowing this would be very useful. For example, 'username' and
>> 'password' fields where the client maintains local copies to save
>> typing.
> 
> Huh.  I think I've actually broken this restriction, with the addition 
> of some JEP-68 semantics or other protocol hints.  Unless, of course, we 
> pick nits over the word "enforce".  Could that mean that as long as the 
> user is allowed to change the value, it's not being enforced?  But in 
> that case, the sentence is nearly devoid of meaning...
> Anyway, I agree with you.

Version 2.0 of JEP-0004 contained the following text:

"A component can provide a default value for a field by setting a 
<value/> in the <field/>.  If a default value is not provided, then the 
Client should not try to enforce one."

The reasons for that restriction seem to be lost in the mists of time. 
The most relevant post I've found in the archives is this:

http://mail.jabber.org/pipermail/standards-jig/2002-March/000536.html

In general the idea seems to be that a form-processing entity can 
specify a default value in the data form of type "form" and that the 
form-submitting entity could enforce that value by, for instance, 
preventing a user from changing it. But I really don't see what that 
buys us, so the restriction doesn't seem all that useful to me (or even 
positively harmful). If the form-processing entity doesn't want to let 
the form-submitting entity change the value for a field, it shouldn't 
provide it in the form (or should make it fixed).

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/20051228/718c94aa/attachment.bin>


More information about the Standards mailing list