Re: XForms Use Case

Robin and Henri,

For what it's worth, I don't think that XForms in HTML5 is an issue in and
of itself - XForms is at the application level on the stack, not the core,
and solutions are emerging there that I think make XForms implementation in
HTML5 core a non-issue. I would agree with Robin, however, that it should be
taken as a use case for the issue of these discussions, specifically the
case where you have intertwined XML namespace content within HTML, where the
semantics of that XML have an effect upon HTML5. It may prove (as I believe
to be the case) that this should be seen as more of a templating issue
(i.e., that this is actually a case of the HTML being embedded within a
theoretical XML construct intended to generate a dynamic template, such as
perhaps XQuery). However, I believe it's a use case that should be formally
considered then ruled out rather than one that isn't even surfaced.

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


On Mon, Jan 17, 2011 at 8:28 AM, Robin Berjon <robin@berjon.com> wrote:

> On Jan 13, 2011, at 08:38 , Henri Sivonen wrote:
> >> 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.
> >
> > The way I'm looking at XForms-in-HTML5 (as well as Namespaces in
> text/html aka. Decentralized Extensibility and modes aka. versioning) is
> that it's bad Process if something keeps popping up as a discussion item
> again and again to occupy attention when the topic has already had its day
> in the Process court. As for group boundaries when considering what items
> have had their day in the Process court, reopening them in a different group
> strikes me as (likely totally unintentional) gerrymandering.
>
> I don't like topics being reopened continuously, but by your own account
> the Forms TF did not see much discussion. Furthermore, I don't think that
> this is gerrymandering as for this TF here pretty much anything that
> concerns the XML/HTML relationship ought to be on the table (it would be
> gerrymandering if we had the mandate to, say, add XForms to HTML5 — but
> thankfully we don't).
>
> FWIW I'm not particularly keen on saving XForms. I invested non-negligible
> amounts of energy in getting it to work for a number of use cases I had with
> only limited success to show for it (those mostly for devices too limited to
> run Javascript, that generally wouldn't be considered very useful now). For
> similar cases today I'd use the likes of Backbone.js, and I certainly would
> adamantly oppose integrating XForms into HTML the way SVG and MathML have
> been.
>
> But if it holds use cases to some here then it ought to be discussed. We
> could possibly reach consensus on some interesting aspects of the problem
> such as when declarative approaches are effectively useful, how to wield the
> Principle of Least Power when designing a language, whether transmitting
> arbitrary XML to user agents is actually a good thing or detrimental to
> universal design, or if there are some useful features from XForms that are
> excessively hard to reproduce in the current Web stack and how we could
> bring them over.
>
> --
> Robin Berjon - http://berjon.com/
>
>
>
>
>