Re: XForms Use Case

If I remember correctly (I was not on the XForms WG then, so don't know what
was happening internally), a lot of the "petering out" came about because
you had the deployment of the WICD path and XHTML 2.0, and with the fairly
strong rejection of the XHTML 2.0 effort on the part of the vendors, the
WebForms TF became a casualty of that.

Additionally, I think that there are a few fairly significant changes that
have taken place since then, not least being both the XQuery in a Browser
effort that I believe will have significant impact on XForms functionality,
Michael Kay's XSLT-JS that also provides a core framework for a consistent
XPath 2.0 capability, and Alain's XSLTForms, which takes a different tack
but similarly provides client support.

This raises several points:

1) XForms is increasingly looking like an application overlay that can be
run independently of specific browser implementations  ... and may, if some
of the work that Alain's been doing is any indication, even be XML
independent (e.g., can run JSON) as far as data models go.

2) Given Henri's comments that the HTML5 parser can in fact parse namespaces
declarations and terms as attributes and elements (i.e., <xf:input> is an
element with a name "xf:input", even if there is no explicit binding to the
namespace that the prefix is binding), it may very well be that the XForms
1.2 WG can adapt the specification to this modality of parsing without
significant change.

3) XPath 2.0 looks like it could be supported via JavaScript within the
browser in the very near future, which in turn makes advanced functionality
of XForms viable.

4) When the web forms/XForms TF was first set up, there was little being
done with XQuery, XML Databases were still largely running proprietary query
languages, and the number of people working with XML Databases regularly was
microscopic. That's changed pretty dramatically in the last few years, and
the XQuery vector I believe is one that's being most readily adopted.

5) Ironically, I also believe that the HTML5 forms work (and a consistent
XBL) make XForms both easier to develop and more viable from an adoption
standpoint, because it fills a niche in the growing XRX market.

However, ultimately I agree with Michael Kay on this - this should be seen
as a GOOD use case where you have XML constructs embedded within HTML5, in
order to see what can in fact be supported with the overall model.

Kurt Cagle
XML Architect
*Lockheed / US National Archives ERA Project*



On Wed, Jan 12, 2011 at 11:36 AM, Robin Berjon <robin@berjon.com> wrote:

> Hi Henri,
>
> On Jan 12, 2011, at 16:58 , Henri Sivonen wrote:
> > However, I think considering XForms should be out of scope and out of
> order, because there was already another Task Force for pondering the
> "architectural consistency" between HTML forms and an envisioned (now dead)
> flavor of XForms. XForms interests lobbied heavily for having the Task
> Force, but once it was set up, the nominated participants from the Forms WG
> did very little to be active and the Task Force expired. Thus, I think the
> XForms community should be considered to have had their chance to have a
> Task Force ponder XForms and HTML5.
> >
> > The archives are at http://lists.w3.org/Archives/Public/public-forms-tf/
>
> I don't think that calling things out of scope and out of order is
> particularly helpful, particularly not in a group that has a vague mandate
> for technical matters but is clearly behooved to explore potentials paths of
> convergence. Yes there's bad history around XForms, but no that is not this
> group's problem.
>
> The Forms TF may have petered out, sometimes these things happen. If
> there's useful, constructive discussion that can be had here instead, it
> shouldn't be prevented.
>
> --
> Robin Berjon - http://berjon.com/
>
>
>
>
>