[whatwg] Web Forms 2.0 - what does it extend , definition of same, relation to XForms, implementation reqs.
hsivonen at iki.fi
Tue Jan 4 00:23:54 PST 2005
On Jan 4, 2005, at 06:13, Bill McCoy wrote:
> HTML". I'm
> not aware that processing arbitrary "Street HTML" (with its
> and CSS arcana) as XML in Java-based systems is a solved problem.
> TagSoup doesn't handle this stuff at all.
Is your concern really about developing the server-side part of a Web
Forms 2.0 app or is your concern about developing a WF 2.0 UA?
DOM or compute the applicable styles on the server. What's your
> 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.
Client-side XSLT is placebo with potentially harmful effects.
If you want to use FooML on the server, fine. Just run XSLT on the
server and send known languages over the wire.
If you send FooML + XSLT over the wire, your XSLT transformation has to
convert your document to (X)HTML+JS+CSS anyway. You end up with the
same goo and the FooML instance traveling over the network is not
useful, because it is not understandable by the UA without a
transformation. Even a search engine would have to apply the
transformation in order to avoid being fooled by spammers.
Client-side XSLT only moves processing from the server to the client
with the added risk that something goes wrong and the page ends up
unreadable. Shipping FooML over the network is not more Semantic Web
friendly, since software written by others are not aware of the
semantics of FooML.
> 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
> data before it's been compiled into a presentational form that is
> programmatic code). The WHATWG proposals to promote scripting, rather
> declarative markup, as the basis of forms data binding and validation,
> to dispense with an XML-based data model separate from presentation,
> seem likely to worsen this situation by leading to more Gmail-like
Eh? WF 2.0 is adding more declarativeness compared to WF 1.0 + JS.
As for declarative validation, it is either inadequate or requires a
functional programming language. You have to revalidate the data on the
server anyway, so you can choose any programming language. If you want
to reuse the same validation code on both client and server, then you
end up needing a JS interpreter on the server as opposed to a Lisp
interpreter or a reformulation-of-Lisp-in-XML interpreter. (When
programming, I'd rather type S-expressions than reformulations of
S-expressions in XML.)
If there was a separate data model and presentation, Google would have
to scrape the presentation anyway in order to avoid SEO spam.
hsivonen at iki.fi
More information about the whatwg