Ah... the old "move the goalposts trick" (or in your case, take them off the pitch completely). Nice move.
However, if you recall I was replying to your assertion that what I wanted (an application building environment that enables distributed applications without resorting to C++ and Java) already existed in the form of Mozilla. I disagreed with you, and said (since you asked me to expand on it) that XForms was quite different to this platform, and in fact much more powerful.
You now say that everyone agrees that adoption of XForms is desirable (I'm pleased to hear that you've now had the chance to take a look at XForms), but that we should take it a step at a time ("... some people are still using the font tag") - so I guess that means that you're at least happy with my main points that Mozilla does not currently provide a suitable plaform to develop web-based applications with.
Your new discussion about whether people's readiness to adopt something is a criteria for its use is, with respect, completely illogical.
Anyway, a few final quick things:
(1) XHTML 2 is not yet a standard, so you are indeed on safe ground when you point out the limited browser support.
(2) As it happens, most web pages probably are built with XHTML 1, since that is simply the XML version of HTML 4 - and since an enormous number of web pages nowadays will be being generated using XML processing they will therefore be using XHTML 1.
(3) Your assertion that SVG is marginal will receive a very big shake-up in the next year, since mobile phones will shortly be including a version of it.
> So if you say xforms should be the base for future web apps instead of html...
Well, firstly it's obvious that HTML is not an application building language, so I assume you mean HTML plus a very large dose of script.
>... you've got to explain why that is. Why is that?
Because it *doesn't* rely on script to get some big things done! Instead it has a large number of back-end features that are available via simple mark-up.
You need to validate a document before submitting? Easy in XForms - just add a schema to the model - not so easy in Mozilla, Opera or IE! You want to create dependencies between nodes in a DOM tree? Perhaps you want an event if node A goes higher than node B, or you want node C to be the sum of all node Ds. Easy in XForms - more spaghetti in Mozilla, Opera and IE.
How about preventing submission if some required value is missing. Easy peasy in XForms. Yet more script in M, O and IE, and which needs to be updated and maintained for every new required value you want to check.
The list goes on; we have platform-independent help, we can define hints with one tag (how many times have you written mouseovers in script?), and new CSS pseudo-classes that allow a control to appear differently if the data is invalid, to name just a few of the many things XForms gives us.
> Mozilla's implementation is over 150k. And that doesn't even do the XForms extensions > to XPath. Not bloat?
Fair point - I agree with you that there is a lot of 'bloat' in Mozilla.
However, surely it would be possible to produce a leaner XPath implementation? After all, it's only a bit of regular expression parsing and then navigating the DOM.
>... the entire product has to fit in less than 1000k here, and that has to include HTML4, > XHTML, XML, namespaces, DOM0, DOM1, DOM2, CSS1, CSS2, XML Events, JavaScript, etc.
Great - and then the only bit you need to add is XPath and you have pretty much all you need for XForms.
> WHAT WG was created not because a specific developer wanted to do it's own thing, > but because the majority of W3C members aren't browser developers. They're plug-in developers. > Some people within the W3C have even stated that the browser is dead. This kind of > environment is openly hostile to the further development of existing browser-based standards.
At the recent Web Applications workshop I did openly say that the "browser is dead". I am not, however "within the W3C", although I am an 'invited expert' on a couple of Working Groups. (And I don't recall anyone else using this phrase.)
My position is simply that to build powerful applications that take advantage of internet technologies - but don't require us to constantly 'drop-down' into C++ or Java - requires a programming environment more powerful than current browsers support. Sure, browsers are great places to save a list of favourites, and most do a pretty good job of rendering HTML, but if we have to wait a few years every time a new mark-up language is bought out - and confusion reigns in the meantime whilst we all try to second guess which browser company will implement what - then there has to be something wrong with the architecture.
So, my view is that the days of the 'monolithic browser' are numbered; it takes too long to update, lacks basic features that any application really should have, and leaves the rest of us at the mercy of a few companies who are more or less radical and 'open', depending on the day of the week.
Of course, it's none of my business whether browser vendors want to create new standards for HTML, but the companies I deal with don't need any more HTML - they've got plenty thanks. What they do need though, is higher-level languages that do more, make application-building easier and quicker, and still deploy as easily as HTML. And for the record, I've been arguing since before XForms became a Full Rec that XForms is an ideal foundation for this.
My proposal at the workshop was for an application environment that allowed these new types of apps to be built, in an open standards/open source way, by defining a 'virtual machine'.
And if we still need somewhere to save our favourites, we can easily use such a VM to build a 'traditional' web browser, but genuinely based on standards.
> Now Opera has been known for ages for being pretty anti-XForms, mostly because integration > of standards such as XForms/SVG would bloat the browser footprint to such an extent that a > lot of mobile device manufacturers might start looking for a different browser...
That's a good point, although it's interesting that at the recent Web Applications workshop the guys from Opera conceded that the only 'extra' piece you needed to add to a standards-based web browser, in order to implement XForms Basic, was XPath. And that can hardly be described as 'bloat'!
The sample you refer to is a little old. We have a 'Hello, World!' sample on our web-site that shows how to build a simple form that is just as compact as the HTML version. But as you'll see from the tutorial, despite being compact, this form packs a lot of power that XForms gives to the form author 'for free'. And more importantly, by using XForms it provides a foundation onto which user interfaces that are far more complex than those usually built with HTML can be constructed.
Slashdot Mirror
Ah ... the old "move the goalposts trick" (or in your case, take them off the pitch completely). Nice move.
However, if you recall I was replying to your assertion that what I wanted (an application building environment that enables distributed applications without resorting to C++ and Java) already existed in the form of Mozilla. I disagreed with you, and said (since you asked me to expand on it) that XForms was quite different to this platform, and in fact much more powerful.
You now say that everyone agrees that adoption of XForms is desirable (I'm pleased to hear that you've now had the chance to take a look at XForms), but that we should take it a step at a time ("... some people are still using the font tag") - so I guess that means that you're at least happy with my main points that Mozilla does not currently provide a suitable plaform to develop web-based applications with.
Your new discussion about whether people's readiness to adopt something is a criteria for its use is, with respect, completely illogical.
Anyway, a few final quick things:
(1) XHTML 2 is not yet a standard, so you are indeed on safe ground when you point out the limited browser support.
(2) As it happens, most web pages probably are built with XHTML 1, since that is simply the XML version of HTML 4 - and since an enormous number of web pages nowadays will be being generated using XML processing they will therefore be using XHTML 1.
(3) Your assertion that SVG is marginal will receive a very big shake-up in the next year, since mobile phones will shortly be including a version of it.
> So if you say xforms should be the base for future web apps instead of html ...
... you've got to explain why that is. Why is that?
Well, firstly it's obvious that HTML is not an application building language, so I assume you mean HTML plus a very large dose of script.
>
Because it *doesn't* rely on script to get some big things done! Instead it has a large number of back-end features that are available via simple mark-up.
You need to validate a document before submitting? Easy in XForms - just add a schema to the model - not so easy in Mozilla, Opera or IE! You want to create dependencies between nodes in a DOM tree? Perhaps you want an event if node A goes higher than node B, or you want node C to be the sum of all node Ds. Easy in XForms - more spaghetti in Mozilla, Opera and IE.
How about preventing submission if some required value is missing. Easy peasy in XForms. Yet more script in M, O and IE, and which needs to be updated and maintained for every new required value you want to check.
The list goes on; we have platform-independent help, we can define hints with one tag (how many times have you written mouseovers in script?), and new CSS pseudo-classes that allow a control to appear differently if the data is invalid, to name just a few of the many things XForms gives us.
> Html has momentum, xforms doesn't.
XHTML 2.0 includes XForms.
> Mozilla's implementation is over 150k. And that doesn't even do the XForms extensions
... the entire product has to fit in less than 1000k here, and that has to include HTML4,
> to XPath. Not bloat?
Fair point - I agree with you that there is a lot of 'bloat' in Mozilla.
However, surely it would be possible to produce a leaner XPath implementation? After all, it's only a bit of regular expression parsing and then navigating the DOM.
>
> XHTML, XML, namespaces, DOM0, DOM1, DOM2, CSS1, CSS2, XML Events, JavaScript, etc.
Great - and then the only bit you need to add is XPath and you have pretty much all you need for XForms.
> WHAT WG was created not because a specific developer wanted to do it's own thing,
> but because the majority of W3C members aren't browser developers. They're plug-in developers.
> Some people within the W3C have even stated that the browser is dead. This kind of
> environment is openly hostile to the further development of existing browser-based standards.
At the recent Web Applications workshop I did openly say that the "browser is dead". I am not, however "within the W3C", although I am an 'invited expert' on a couple of Working Groups. (And I don't recall anyone else using this phrase.)
My position is simply that to build powerful applications that take advantage of internet technologies - but don't require us to constantly 'drop-down' into C++ or Java - requires a programming environment more powerful than current browsers support. Sure, browsers are great places to save a list of favourites, and most do a pretty good job of rendering HTML, but if we have to wait a few years every time a new mark-up language is bought out - and confusion reigns in the meantime whilst we all try to second guess which browser company will implement what - then there has to be something wrong with the architecture.
So, my view is that the days of the 'monolithic browser' are numbered; it takes too long to update, lacks basic features that any application really should have, and leaves the rest of us at the mercy of a few companies who are more or less radical and 'open', depending on the day of the week.
Of course, it's none of my business whether browser vendors want to create new standards for HTML, but the companies I deal with don't need any more HTML - they've got plenty thanks. What they do need though, is higher-level languages that do more, make application-building easier and quicker, and still deploy as easily as HTML. And for the record, I've been arguing since before XForms became a Full Rec that XForms is an ideal foundation for this.
My proposal at the workshop was for an application environment that allowed these new types of apps to be built, in an open standards/open source way, by defining a 'virtual machine'.
And if we still need somewhere to save our favourites, we can easily use such a VM to build a 'traditional' web browser, but genuinely based on standards.
> Now Opera has been known for ages for being pretty anti-XForms, mostly because integration ...
> of standards such as XForms/SVG would bloat the browser footprint to such an extent that a
> lot of mobile device manufacturers might start looking for a different browser
That's a good point, although it's interesting that at the recent Web Applications workshop the guys from Opera conceded that the only 'extra' piece you needed to add to a standards-based web browser, in order to implement XForms Basic, was XPath. And that can hardly be described as 'bloat'!
The sample you refer to is a little old. We have a 'Hello, World!' sample on our web-site that shows how to build a simple form that is just as compact as the HTML version. But as you'll see from the tutorial, despite being compact, this form packs a lot of power that XForms gives to the form author 'for free'. And more importantly, by using XForms it provides a foundation onto which user interfaces that are far more complex than those usually built with HTML can be constructed.
Mark Birbeck
CEO and CTO
x-port.net Ltd.
Download our XForms processor for IE
from http://www.formsPlayer.com/