I'm surprised to get a response back so quickly, and for the most part I'm actually in agreement with you, but let me comment inline:
>> My $0.02 after using XForms extensively (with @John Clark) for patient record data collection (http://copia.posterous.com/desiderata-and-architectural-constraints-of-w
I find it significant that you've HAD experience working with XForms. I'm not disagreeing with their utility - far from it - only trying to figure out how to get it out of the XML-only ghetto that seems to be a gating factor for adoption.
>> XForms exists at the upper end of technical complexity:
I'd definitely agree the learning curve is significantly cheap, but I think the potential for automation and templating is much more powerful than anything else out there in my experience
The problem I'm highlighting here is that the domain involved is generally at the enterprise level, for use in data-centric applications. These currently represent a comparatively small portion of all websites on the web, and as such tends to command a low priority for web developers looking to build the latest and greatest in the consumer sphere. As data-centric applications become more of a factor on the web (which I believe will be the case), the demand for XForms will likely rise as well.
>> Less X.
JSON, inbound and outbound: Seems to sacrifice the power of declarative programming for closer integration with the browser framework. A balance would need to be struck
>> XPath2/XQuery support:
I disagree, I have yet to find a motivation for adopting the next generation of XML standards (which have their own steep learning curve that is the main reason why I haven't bothered moving off XPath/XSLT). But this may just be due to the requirements I was working with
It's worthwhile. XPath 1.0 suffers from the fact that the underlying data model assumed that all nodes were in fact part of a single document, and that restriction prevents a great deal of functionality. Sequences, the logical successor to XPath 1.0 nodesets, are considerably more robust on all fronts, and they work especially well when dealing with heterogeneous data sources. The curve is also not all that steep - the basic expression language doesn't change in XPath 2.0, you just have a larger API of available functions to work with, and more significantly you have the ability to define modular extensions in a consistent manner not only in the host language, but within XQuery or XSLT2. FWIW, I find XSLT 1.0 far more limiting now, though I use XSLT 2 and XQuery both far more extensively.
>> Internal user variables:
I definitely agree and this was a major pain point for us.
Me as well. You CAN get by with node bindings, but they are not quite the same things, and in many cases the biggest value of variables is the ability to collapse extensive XPath expressions.
>> Namespaceless elements:
I don't find this argument compelling and it seems to be more an issue of the learning curve of XML as a deterrent to its adoption for use in the web.
>> jQuery and HTML5 compatibility:
>> Re: the relevance of XForms in 2012:
I cannot imagine using jQuery/DHTML instead of XForms to meet the requirements we had (automation, templating, etc.) that emphasized the value of declarative programming. Perhaps our requirements were an exception.