On 12/24/08 1:38 AM, Brett Zamir wrote: > Hi, > > 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".
This means that if you receive, say, a list-multi field with 5 options, when you return the form you can't include the same list-multi field with 6 options (thus adding an option that was not included in the field you received). Does XEP-0122 suggest that you can do that? I suppose it is implied by the following text in Section 3.2: For "list-single" or "list-multi", to indicate that the user may enter a custom value (matching the datatype constraints) or choose from the predefined values, the <validate/> element shall contain an <open/> child element. I'll need to think about that a bit. It would help here (and elsewhere throughout XEP-0122) if we had more examples. > 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? I don't know what that means. I'll need to ask the XEP author about it. > 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 > list? Could you provide an example? > 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"? Regex matching for JIDs makes some sense to me, but range matching does not. > 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). I agree that it would be good to specify range validation more carefully. > 6) Shouldn't "fixed" be a type not allowed for "open" validation in > Table 1? Yes. To your other points... http://mail.jabber.org/pipermail/standards/2008-December/020827.html Also, as for Table 1, as note 10 states, "If a particular field type is not listed, the display MAY include validation support, but is not expected to do so", although it is pretty obvious, I think the "boolean" type should be added to the chart to forbid it for each type of validation (as with "hidden"). Agreed. http://mail.jabber.org/pipermail/standards/2008-December/020828.html Also on Data Forms Validation, why are jid-multi and jid-single discouraged for use with Basic validation, or even 'hidden' for that matter, if results ca be verified? I'm not sure. It seems that you could at least match the datatype. I think this spec needs to be revised to clarify these points. It would also benefit from lots more examples. Brett, do you have examples to share, or shall I work with Matt Miller on that? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
