[Standards] Data Forms Validation

Brett Zamir brettz9 at yahoo.com
Wed Dec 24 08:38:46 UTC 2008


I love the Data Forms spec and the Data Forms Validation spec, but I 
have a number of questions and thoughts relating to Data Forms 
Validation, XEP-0122.

1) If Data Forms validation is approved, list-multi and list-single 
would need to changed as it says in section 3.3 of XEP-0004, that they 
"MUST NOT insert new options".

2) In 3.2, it states "Any validation method applied to a field of type 
"list-multi", "list-single", or "text-multi" (other than <basic/>) MUST 
imply the same behavior as <open/>, with the additional constraints 
defined by that method." What does this mean exactly? Why should the 
other methods require behavior like <open/> which allows open-ended 
choices for lists?

3) What should one do if one wants an open-ended list of JIDs? If 
<open/> validation should be used with jid-multi/jid-single (as 
expressly allowed in Table 1 of Data Forms Validation), what if one also 
or instead wants a jid-multi to be validated separately as with 
text-multi? Should there instead be a JID datatype, so a 
list-multi/list-single could be used in contrast to say text-multi which 
didn't arrange (or for submissions, require) the items in a constrained 

4) If list-multi can become open-ended, why are range and regex 
validation discouraged for it in Table 1 in DFV? And what's wrong with 
jid-multi being validated against regex if they could be made to 
validate separately (as would seem to make sense). And shouldn't 
"jid-single" be listed as being not allowable under "range"?

5) Under "range" in Table 1, it states that "'For text-single', allow 
user to increment/decrement through possible values". What about decimal 
types? These can fall in a range, but not really be incrementable. I 
think discussion of increment/decrement (and about discussion of display 
issues in general) is a helpful one but might as a result of this be 
more suited under a discussion of data types and display. This would 
also allow mention, for example, that a date or time type could be 
presented with a calendar/clock selection or display, an integer could 
present an incrementing text box, a decimal type could be presented as a 
slider, etc. (or a progress meter in the case of results).

6) Shouldn't "fixed" be a type not allowed for "open" validation in Table 1?


More information about the Standards mailing list