[whatwg] Web Forms 2.0 - what does it extend , definition of same, relation to XForms, implementation reqs.
jg307 at cam.ac.uk
Tue Jan 4 07:29:16 PST 2005
Bill McCoy wrote:
>I find it odd that some WHATWG members argue that transmitting arbitrary XML
>data over the wire to clients is a bad idea (
>http://ln.hixie.ch/?start=1064828134&count=1 )given that the solutions
>and other tricks - are so much less "Semantic Web" friendly. To pick an
>extreme example, Google folks admit that search-indexing a Gmail screen
>would be extremely challenging (they themselves index the raw data of
>course, but that's the whole point - it's much easier to process structured
>data before it's been compiled into a presentational form that is partially
>programmatic code). The WHATWG proposals to promote scripting, rather than
>declarative markup, as the basis of forms data binding and validation, and
>to dispense with an XML-based data model separate from presentation, would
>seem likely to worsen this situation by leading to more Gmail-like
It's not only an extreme example, it's a terrible example. Google have
repeatedly shown that they have no interest in using the semantics
available in HTML, let alone whatever additional complexity is provided
by XForms - just see any Google search results page. This is clearly not
an inability to understand the benefit to the client of good markup and
so must be a conscious decision on the part of Google. So the fact that
GMail is hard to index is just as likely evidence of malice as it is
evidence that better data/presentation separation is needed.
Even allowing that your example is misguided, I'm not sure I believe the
rest of the argument either. In order to believe that HTML should be
starved in order that XForms should flourish, you have to take the
position that there will be a migration to XForms (and XHTML) from HTML.
In order to believe that this will offer a significant advantage to the
semantics of the web, you have to believe that authors will tend to use
the new features offered by XForms in the way that they are designed to
be used. In practice, I'm thoroughly unconvinced of the first and
skeptical of the second.
At the moment, there is simply _no_ way of migrating away from "street"
HTML. XHTML is fundamentally incompatible with "street" HTML because the
processing requirements of HTML are satisfied by a negligible proportion
of all HTML documents. XHTML is not supported in any meaningful way by
the world's most commonly used web browser. There are few existing CMS
solutions that are able to produce XHTML reliably, let alone arbitrary
XML, and few users who understand the technical requirements of XML. The
combination of all these factors makes it very hard to migrate away
from HTML to anything that is not explicitly compatible with it.
Even if people could migrate away from HTML, it is doubtful that they
would suddenly learn the benefits of sending semantic documents over the
wire, nor the ability to understand complex specifications well enough
that they would produce high-quality documents. I would expect that in
XForms, as in HTML, if there is a way to hack a solution that
looks/works as expected then authors will use that at least as often as
they use the neat solution provided by the language.
The major advantages of the WHATWG specs over XHTML/XForms are
1) Backward compatibility. They can be used in situations where there is
existing content that must be integrated and a limited migration budget
(i.e. most real world situations)
2) Limited additional complexity. Because Web Forms 2 is close to HTML 4
and, in particular, because it does not switch to a model in which
everything is done declaratively, it is familiar to existing authors
and, as a consequence, is more likely to be understood, adopted, and
used in a way compatible with the specification.
More information about the whatwg