XForms has a problem
XForms is the W3C’s XML language for programming forms on the web. It handles new user interface controls, better data validation, and easier form submission.
It does this by strictly following the "MVC" approach to data management – a ‘model’ is stored in the XHTML head, containing data structures bound to user interface form controls. When you enter values into the form controls, the model automatically updates too, and it’s the model that gets submitted.
In order to get the model to work, XForms defines an incredibly powerful binding engine, like a spreadsheet where cell values can depend on each other. It’s here that I have the problem. Why is the binding technology written inside the XForms spec? It’s useful for so many purposes (e.g. spreadsheets) that have nothing to do with forms – or even XHTML - and it stands on its own as a fundamental use of XML.
For example, I might have an SVG document where I want to bind the width of a circle to the length of a line. I can’t use XForms binding, because it’s not an XHTML document and even if it was, I don’t want to follow the MVC approach.
So, the That way, all XML developers will gain a new technology that provides so much value, especially in animations. And XForms will become much simpler, and more targeted towards its role in enabling web forms.
2 comments:
Chris,
A big part of the reason why there isn't a generalized bind has been because there have been a number of (somewhat competing) binding architectures active within the W3C. One that has run the gauntlet recently (and may be more relevant to the SVG case) is XBL2, which I generally like with the exception of the fact that its selector model is based upon CSS selectors rather than XPath.
Note that it is also possible to bind SVG from within an XForm - I have an SVG example up at my XForms.org site. It's not pure XForms - there's still some ambiguity about serializing complex content out of the <xf:output> object which I had to do a binding work around, but the principle nonetheless does hold.
Kurt,
Thanks - you're right, but I think we're using different definitions of "binding". XBL2 uses it to mean assigning extra behaviours and properties to HTML elements - "behavioural binding". XForms uses it to mean automatically calculating the value of a node, using other nodes - "value binding".
They're especially different when you consider the processing models - XBL2 is procedural (using events like onChange), whereas XForms is functional (like Microsoft Excel, when a node value changes, dependent nodes change automatically to maintain the binding relationship). I explain this in more detail in my blog.
So I don't think XBL2 and XForms compete, except over the definition of the word "bind". They have different purposes. Even if every browser supported XBL2 fully, I still think there would be a need for XForms-style binding (independent of the XForms spec), because it should be useful to establish value binding between any nodes in any XML document :)
Post a Comment