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

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. 

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. 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.

--Bill McCoy
Adobe Systems Incorporated
bmccoy at adobe.com


-----Original Message-----
From: Henri Sivonen [mailto:hsivonen@iki.fi] 
Sent: Monday, January 03, 2005 8:30 AM
To: Bill McCoy
Cc: whatwg at whatwg.org
Subject: Re: [whatwg] Web Forms 2.0 - what does it extend , definition of
same, relation to XForms, implementation reqs.

On Jan 1, 2005, at 20:13, Bill McCoy wrote:

> Whereas Web Forms 2.0, being a script-intensive solution built on an 
> ill-defined non-XML language is clearly not going to be nearly as easy 
> to handle in server-based workflows. Indeed one of the world's largest 
> web sites maintains a large-scale Windows server stack merely to run 
> MSHTML server-side. While keeping web documents arcane and difficult 
> to process may be a source of commercial advantage to browser 
> manufacturers it doesn't seem like a great solution for the industry 
> as a whole.

I assume you mean HTML when you say "ill-defined non-XML language", because
Web Forms 2.0 supports an XML submission format.

Non-Microsoft enterprise server systems that deal with XML are typically
implemented in Java. Processing HTML as XML in Java-based systems is a
solved problem. The app internals are written for XHTML and conversion is
done on the IO boundary. TagSoup by John Cowan is used on input an HTML
serializer[2] is used on output.

If it looks better, one could consider WF 2.0 syntax an extension the XHTML
that has been immediately backported to HTML. :-)

[1] http://mercury.ccil.org/~cowan/XML/tagsoup/
[2] eg. 
http://iki.fi/hsivonen/cms/src/fi/iki/hsivonen/xml/HtmlSerializer.java

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

Received on Monday, 3 January 2005 20:13:27 UTC