Re: Model-driven Views

Rafael,

I am co-chair of the W3C Forms Working Group.

As Charles McCathieNevile pointed out in this discussion:

 >It probably makes sense to ask the Forms group as well, given that it
 >doesn't require much squinting to get to the perspective where you're
 >pretty much reinventing a wheel they've already got two of.

And as Dave Raggett pointed out:

 >Note that a particularly long standing effort on applying the MVC design
 >pattern to the Web is XForms where the model is represented as a DOM
 >tree.

We're very interested in continuing this discussion with you.

Please see http://www.w3.org/TR/xforms11 for our current W3C 
Recommendation and http://www.w3.org/MarkUp/Forms/ for our group page 
with implementation news, courses, etc.  You'll find our Working Group 
has over ten years of W3C Recommendations and many implementations of 
MVC and declarative, markup-based interfaces to (and extensions of) 
underlying HTML functionality.

We're currently quite interested in promoting declarative interfaces to 
some of the new functionality that HTML5 is pouring into desktop and 
mobile browsers, as we have done with existing functionality from the 
HTML4/XHTML1 series.

Additionally, we're working to try to bring forward some of the stagnant 
XBL2 work in a form that gives the web a markup-based component 
architecture.

Finally, we are interested in your point in 
[http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0428.html] that 


   We can create a feature which is "fast by default". Libraries almost 
never do.

The Mozilla implementation of XForms used Mozilla XBL and underlying C++ 
code (Transformix and others) to provide a fast implementation of 
XForms.  Unfortunately, it was limited to Mozilla.  Recently, a 
cross-browser approach has lately taken hold, and the more recent 
XSLTForms and Ubiquity Forms projects provide a JavaScript library-based 
approach to implementing XForms in today's desktop and mobile browsers.

We recognize that not everyone wants an MVC and markup based approach to 
declarative programming, but given that this is your area of interest, 
we'd be very interested in working with you to help design new APIs for 
browser features that enable implementations of XForms to be fast, 
stable, and secure in new desktop and mobile browsers.  Upper level 
libraries could make use of these features to provide convenient 
interfaces for web authors, and so the lower-level features themselves 
are free to be designed in a more specific fashion.  Limiting what 
fundamental capabilities are added to those which are necessary for a 
number of approaches may, and then letting the upper-level 
implementations provide convenient interfaces may answer Maciej's 
concern that "API is forever, on the Web" and echo Olli's comment 
"better to add primitives which allow creating script libraries."  (For 
an example of how we have done this, see XForms submission element with 
XHR, or XML Events wrapping of DOM Events. )

In particular, we'd love to see support for the shadow-DOM notion from 
XBL2 so that a component system along the lines of XBL could be 
developed and written.  For XForms, the benefit would be this:  a 
component system would allow developers to implement XForms via 
expansion into underlying browser facilities dynamically, and would also 
allow XForms authors to design their own components made up of XForms 
and other HTML and SVG elements (component widgets, macros, what have 
you).  Since such a component system would be orthogonal, it would be 
useful to all, whatever form of expression your preference for MVC takes.

Thank you,

Leigh L. Klotz, Jr.
Senior Software Architect
Xerox Corporation
Co-Chair, W3C Forms Working Group

Received on Wednesday, 4 May 2011 23:04:02 UTC