[Standards-JIG] JEP-0004 Data Forms issues

Joe Hildebrand hildjj at gmail.com
Wed Dec 28 02:52:22 UTC 2005


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'."
> How is it envisaged that the multiple values for each option in a  
> field
> would be presented to the user?
> [I would have expected that if the field type is 'list-multi' then the
> *<field/>* element MAY contain more than one <value/> child.]

This looks like a typo to me.  I think the intent was this:

<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>polls</value>
   <value>search</value>
</field>


> 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.

Too bad 4 is final.  Any process suggestions for what to do next?

-- 
Joe Hildebrand





More information about the Standards mailing list