Architectural Consistency Requirements for Forms

Here's one more that is not called out explicitly in 1..8:

9)  Given N controls that  are inter-dependent, enable "O(N)
    wiring" rather than requiring "O(N^2) wiring". 

In the XForms world, this is met by having a data model to which
    controls are wired. In the interest of consistency, and for
    enabling the smooth on-ramp from HTML Forms that Mark Birbeck
    has elucidated earlier, we should ensure that an author who
    starts off writing a plain old HTML Form (i.e. no explicit
    data model) can later add in a data model and additional
    wiring without having to re-author the entire form.
 



Maciej Stachowiak writes:
 > 
 > 
 > 
 > Last night, I discussed with John Boyer and others the meaning of the  
 > architectural consistency goal for HTML Forms and XForms. Here was  
 > John's first cut at a list of requirements. I think these are a fine  
 > starting point as a set of architectural consistency requirements;  
 > perhaps the Forms Task Force can refine them further. My expectation  
 > is that both the next version of HTML Forms and the next version of  
 > XForms should satisfy a list of requirements along these lines.
 > 
 > I'm quoting him directly, but these probably want wording clean-up if  
 > they are to be used as a starting point.
 > 
 > It was suggested to me by others that Web Forms 2 (our current  
 > proposed starting point) may already satisfy some or all of these  
 > requirements, which would be good news for the possibility of meeting  
 > our architectural consistency goals. I would appreciate it if a Web  
 > Forms 2 expert (perhaps Ian or Anne) could address whether Web Forms  
 > 2 satisfies any of these requirements, with examples.
 > 
 > 
 > 1) I want a tag set that means the same thing whether it is  
 > serialized as XML or not
 > 
 > 2) I want a tag set that maps to data model constructs in the XForms  
 > architecture where appropriate
 > 
 > 3) I can see there is a desire to attach data model properties to UI  
 > controls; fine, so let the names of the UI controls suggest the data  
 > model... and let the hierarchic structure of the UI suggest the  
 > structure of the data... and let the properties defined on those  
 > controls suggest properties on the data.
 > 
 > 4) It should be possible to submit the suggested data as XML, and to  
 > indicate either receipt of a new replacement document or a new data
 > 
 > 5) It should be really easy to grow or shrink "repeated" data (as  
 > expressed by repeated controls)
 > 
 > 6) it should be easy to receive prepop data for things that repeat  
 > and yet still have a way to add new "rows" that are empty
 > 
 > 7) It should be possible to delete until a repeating construct is  
 > empty and then be able to insert to get an empty one row "Table"
 > 
 > 8) It should be possible to express relevance, readonlyness,  
 > datatype, constraints on value, and calculated value
 > 
 > 
 > This is a great set of requirements because it is all about  
 > functionality, rather than syntax, allowing us to design HTML forms  
 > to provide features to satisfy these, but using syntax that is  
 > backwards compatible and degrades gracefully.
 > 
 > John mentioned that these thoughts were off the cuff, and he may have  
 > forgotten some important points. I would appreciate it if XForms experts
 > 
 > Regards,
 > Maciej
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Thursday, 3 May 2007 17:49:55 UTC