Smarter Everyone, Smarter Everything, Smarter Everywhere
John M. Boyer 060000VMNY 744 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 962 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 985 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 992 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 994 Views
Well, it's only two days into the W3C Tech Plenary and already I have enough things to write about that I cannot possibly inflict it all upon you in one blog entry. So, I'm just going to give an overview so that I'll remember to talk about some of this stuff in more detail later.
But first, an excellent bit of humour from another long-time W3C member who also happens to live in Canada (a little knowledge of Canadian geography and politics helps with this one):
Liam: Where do you live?
John: I live in Victoria, which is near Vancouver.
Liam: Oh, I live in Ontario, which is near Toronto.
Well, it was funny when Liam said it :-)
Anyway, for the first two days here I have been able to sit as observer on other working groups as well as have some individual discussions of some importance. Here is a summary:
The chat with Liam also included his hopes for XForms eventually adopting XPath 2.0. More about this in another blog entry...
Sat in for a while on the Compound Document Formats working group. Major topic of discussion was event flow between DOMs. How do a parent and child document come to agreement on whether events flow between them? Where does the capture phase start? More to come...
Sat in on the XHTML working group. Major topic: XML events. Specifically, how to upgrade XML events to offfer authors the ability to dynamically add and delete listeners after the document is first loaded. There's not a lot of complexity semantically, but the discussion of the vocabulary involved led to a very exciting discussion about the meaning of namespaces, especially as applied to attributes. This will be a beaut of a blog entry...
Talked with Doug Schepers, who was very interested in having a declarative way of doing AJAX-like things so that the functionality could be securely enabled even with scripting off. I told him I would demo it tomorrow in my part of the Rich Web Application Backplane panel. It's called XForms. More to come...
Finally, had a very good chat with Jose Kahan and Thomas Roessler about making progress on correcting the impedance mismatch between canonicalization and xml:id, with implications for a revision of XML Signatures. Lots more to come...
Stay tuned for more on these points!