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
