[whatwg] Web Forms 2.0 - what does it extend , definition of same, relation to XForms, implementation reqs.

[Henri Sivonen]

On Jan 4, 2005, at 06:13, Bill McCoy wrote:

> By "HTML" I mean "HTML+JavaScript+CSS": what Opera calls "Street 
> HTML". I'm
> not aware that processing arbitrary "Street HTML" (with its 
> DOM-scripting
> and CSS arcana) as XML in Java-based systems is a solved problem.  
> Certainly
> 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? 
Normally, you would not need to be able to run JavaScript against the 
DOM or compute the applicable styles on the server. What's your 
scenario?

> 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
> already widely employed in Street HTML - encoding data in JavaScript 
> arrays
> 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 
> 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
> JavaScript-centric web applications.

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.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/