Smarter Everyone, Smarter Everything, Smarter Everywhere
John M. Boyer 060000VMNY 812 Views
XForms 1.0 Second Edition has been published today at http://www.w3.org/TR/xforms/
To get an idea of the quality and quantity of improvements made to XForms, please see http://www.w3.org/2003/10/REC-xforms-10-20031014-errata.html
Based on this improved foundation, the XForms working group will now be focusing its energies on the completion of XForms 1.1. To get an idea of what will be available, check here: http://www.w3.org/TR/xforms11/
The one comment I would make about the above working draft is that the we will almost certainly revert to using the same namespace currently used for XForms 1.0, and instead use some mechanism within the language to do versioning.
In keeping with my prior post about signatures and namespaces, it is important to version a language either internally or by updating the namespace URI. Previously, we chose the namespace route because XForms is designed to be hosted within another language, so it has no root element of its own to which a version could be attached.
However, XForms 1.1 is using some special schema wizardry that allows it to have a "chameleon" namespace, which will make it easier to import XForms into a host language like XHTML without namespace qualification. I'm not a big fan of doing this, especially for host languages other than XHTML because it becomes harder to find the XForms within another document and host the XForms functionality separately from the original host language.
Nonetheless, the feature is there and it occurred to me during the W3C tech plenary that the chameleon namespace could be used to put XForms 1.1 back into the XForms 1.0 namespace. That means that XForms processors trying to determine what semantics to attach to the vocabulary need some other way to make their decisions. So we simply have to solve the versioning problem without using a change of namespace URI.
The camp that wanted us not to change namespaces will be happy. My own XSLTs will be happy too.[Read More]
John M. Boyer 060000VMNY 1,073 Views
The Workplace Forms Designer allows the form author to use an XML schema to automatically generate the instance data for an XForms model. The data nodes are needed to allow drag-and-drop associations to be created between the data and user interface components. You can drag from an existing UI control onto the data to make the association, or you can drag the data onto the form design canvas to cause the creation of a UI control that will then be bound to the data node. Either way, in XForms the association is made between instance data nodes and UI controls.
This is true even when the XML schema contains an element whose content is a choice. When this happens, the Workplace Forms Designer generates data according to the content of all possible choices. This allows form design to proceed for each of the possible choices. The expectation from XForms is that the form author will make all of the possible choices be non-relevant except the one actually chosen by the end-user. For example, if you have a choice of address block based on country selection, once you select "UK" then you get the UK address block, and once you select "US" then you get the US address block, and so forth. All address blocks other than the one for the selected country become non-relevant.
The use of non-relevance in XForms is significant. It affects two things, but the most important is that all non-relevant nodes are removed from XML data at the start of submission processing. This is important because an XML element with a schema choice content model is not valid until all but one of the choices is removed. This is called "pruning non-relevant nodes" in XForms, and it means that XForms does not expect instance data to be schema valid
John M. Boyer 060000VMNY 1,080 Views
A lightning talk at the tech plenary is about 3 minutes long and introduces something very specific to the W3C.
I gave a lightning talk on the effecs of adding or changing the stuff in a namespace. You can see the diagram and notes here: http://www.w3.org/2006/03/01-Boyer-Lightning/SignaturesAndNamespaces_Boyer.html
Basically, got a lot of nods all the way up to TimBL himself when I said you either have to use a new namespace, or you have to internally version the language so that old processors for a vocabulary don't try to render new documents with graceful degradation of unrecognized content when the documents have been signed.
Too bad this is exactly what happened with xml:id. It got added to the XML namespace rather than some other namespace, and the version of XML didn't change. Lo' and behold, it broke something. When doing a C14N of a document subset containing orphaned nodes, C14N copies XML namespaced attributes into orphaned nodes when they don't contain their own settings for the nodes.
This is good for xml:space, xml:lang and xml:base, but it isn't good for xml:id.
Truth be told, it's kind of an edge case. In XFDL, we don't even allow you to orphan nodes when signature filtering because the structure of the language is such that an orphaned node is useless without its ancestral chain.
Still, while the problem doesn't affect Workplace Forms, we (in W3C capacity) will still endeavor to fix the problem.
Since the ship has already saled on what namespace xml:id lives in, we're going to be doing a new C14N algorithm that doesn't do the inheritance behavior on xml:id OR one that doesn't do the inheritance behavior except for lang, space and base.
Actually, it's a little more complicated than that, since either of the above choices means that C14N will again be broken in the future when either a non-heritable or a heritable attribute, respectively, is added to the XML namespace.
I think we may have to add a parameterization to the new C14N that allows the author to specify the heritable attributes. This will allow document authors to keep up with adjustments to the XML namespace.
The core WG feels that further additions to the XML namespace are highly unlikely, but I'm not convinced. Just at this tech plenary alone, I heard calls for xml:role (like HTML's role) and xml:profile (like DOM's hasFeature, it would declare that a document has a feature so the processor needs to have the feature or the document won't work). In the past, I've heard a need for xml:src (like HTML src, except HTML's default is wrong-- content should override the attribute rather than the reverse). And my personal fave would be xml:compute to express that the content of an element is computationally derived from other content. The list really does go on once you start to think about XML as an intelligent object...
John M. Boyer 060000VMNY 1,085 Views
The powers that be asked the dW bloggers to help spread the word about the download availability today of DB2 Viper Release Candidate 1.
Please see www.ibm.com/db2/viper
You can also get more info from
Anyway, why does this make sense on a blog about Workplace Forms?
As I said before in this blog, the purpose of a form is to collect data. If you want to collect data about a pizza order, you don't want us, but obviously there are more sophisticated information needs than that, right!
Question is, once you've got the data, what do you do with it?
There's always a server side to any web application. Products like DB2, Content Manager, and Portal Document Manager are about providing high strength persistence tiers for the consumption of data collected across an enterprise or across enterprises. Products like WebSphere Application Server and WebSphere Portal Server are about creating that middle layer that creates the logical bridge between from the point where you have the data to the point where you know what to do with it (something has to decide where to put the data, what data to retrieve, etc.).
And IBM Workplace Forms is there to put a beautiful face on it all by intelligently collecting data of any level of complexity while providing a richly textured user experience. And DB2 Viper is an especially good fit with IBM Workplace Forms because our forms contain XForms, which is a pure XML play, and the most significant addition to DB2 in Viper is the native-XML data model.
John M. Boyer 060000VMNY 1,101 Views
The IBM Workplace Forms product suite will make your life easier. It simplifies by an order of magnitude the work of creating and maintaining forms applications.
Sometimes I hear people say "Forms. Hey, name, address, pepperoni, extra cheese. I know about forms. Nothing new there." Well, guess again because we're not talking about those kind of forms. After all, hey, you do already know all about those kind of forms.
In this blog, I'd like to be able to talk to you, the developers in our community, about what makes IBM Workplace Forms different and better for forms applications. We'll talk about bigger picture trends, architectures and models, but in at least equal measure we'll talk about the nitty gritty, the pointy brackets, the XForms, the XML and other technologies behind it all. And best of all through our dialogue we'll develop a community of the most efficient and effective forms application developers on the planet.
For now, let's start with some links you can use to get your hands on some software to test drive.
Here are the reference manuals and user docs for the currently released version:
Now, for me, here's the really exciting link. Our upcoming new version will be available in 26 languages and combines rich XML processing capabilities of XForms with the precision presentation, rich user experience and superior authoring experience of Workplace Forms.
Here's a link to the current public beta:
(This is the Lotus main beta page. The direct link is http://www.lotus.com/ldd/beta/workplaceformsbeta.nsf/)