On Aug 31, 2006, at 17:45, Mark Birbeck wrote:
But I do feel that your comment reflects an old-fashioned view of
internet technologies.
I think a big part of the rift between the XForms/SVG-as-app-platform
camp and the WHAT WG camp is that the former considers Web browsers
old-fashioned. (I don't consider browsers old-fashioned.)
With the installation of
XForms functionality *once* you get to build a large part of your
desktop application using declarative mark-up.
I think declarativeness is overrated when it comes to apps. What's
*so* bad about an imperative scripting language, really? (Lisp may be
theoretically nice, but people still write desktop apps in imperative
languages. And yes, I have written Scheme programs myself.)
The *one* justification for declarativeness over JavaScript that I
have heard from an XForms implementor was that you can statically
analyze which form fields affect other form fields (before the user
actually triggers any changes) so that software can describe the
relationships in audio when the user is driving a car without the
form author providing an explicit audio UI. I may be missing the
point, but I wouldn't want to fill in tax forms when I'm driving. :-)
BTW, the idea of writing a lot of verbose XML instead of writing a
few lines in an imperative programming language makes me have
enterprisey flashbacks of J2EE stuff that saves developers the
trouble of writing a few lines of Java by making them write a huge
lump of XML configuration files.
And the different
XForms implementations reflect this--you can go from a server-hosted,
zero-install solution like Orbeon or Chiba
As Lachlan pointed out, the Orbeon style is exactly the
implementation style that is presented in the WF2 spec.
XForms is also requried to be used within an XML document served
with an
XML MIME type, such as application/xhtml+xml...
That's not true. XForms not only does *not* mandate a MIME type, but
it doesn't even mandate a specific host language!
XForms says it is an XML language and XML requires an XML MIME type.
Even if that point of view may feel uncomfortable, the point of view
that real-world browser engines (Trident, Gecko, KHTML/WebKit and
Presto) don't parse text/html as XML is an observable fact, so for
all practical processing purposes text/html is tag soup--not XML.
(in the same way as Acrobat, for example)
On the point of Acrobat and MIME types, the PNG spec (to pick an
example) doesn't need to say that it is inappropriate to send PDFs
labeled as image/png. (Likewise, looking for normative references on
what text/html *isn't* is the wrong approach.)
I don't really understand this, although I'm trying. Just so that
people aren't getting the wrong impression here, an XML document does
not cease to be XML just because it is delivered with the wrong MIME
type
For practical purposes it does, if it isn't parsing using a
conforming XML processor in real-world implementations.
is that MVC architecture is a 'good thing'; why in the world
would people using such concepts want to go backwards to HTML forms
when they've spent years trying to escape their limitations?
You can have MVC in JavaScript. In fact, I have implemented one such
app (but can't demo it due to its proprietary behind-a-firewall
nature). It had an XHR-loaded/saved XML document as the M, an HTML
+CSS document as the V and a JavaScript program as the C.
* so to know how many pages are delivered as XHTML you'd
need to know what systems are doing the delivering--the
MIME type tells you nothing.
It tells you what code path real browser engines use for processing
the document.
My guess is that a lot of systems are generating pages on the fly on
the server, and are using XML-related tools to do so, and when the
page is ready, the server tacks the text/html MIME type on at the last
minute. But of course I can't prove that, no more than you can prove
your view that when people use the text/html MIME type, they are
delivering 'real' text/html pages.
PHP-based systems, JSP-based systems, ASP-based systems, etc., etc.
all use string-based tag soup templating methods. It is notoriously
difficult to bullet-proof them to emit real XML.
It seems to me that systems based on DOM/XOM, SAX or XSLT are
relatively rare. And if you really have a truly XML-based system, it
can emit SAX events. Once you have SAX events for an XHTML 1.0
document, you can serialize as HTML 4.01 trivially. And the
serializer is not a particular burden, because you need a special-
purpose serializer for the infamous Appendix C as well (an
inconvenient detail that is often conveniently ignored).
Our XForms/Ajax implementation sits on top of any Ajax library--so
will work with YUI, Scriptaculous, etc. So if Amazon and GMail can use
an Ajax library, then they can use XForms. It's no big deal.
What happened to end-to-end declarativeness?
(Just as an aside, the kind of implementation you mentioned before,
where scripts are used to provide support for WF 2.0 in browsers that
don't provide such support natively is not beyond the abilities of
XForms developers! It's really not that difficult!)
Except WF 2.0+JS-based apps don't pretend to be fully declarative.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
