The W3C recommended a migration to XML of web content in January 2000. It's called the XHTML recommendation. The language was further updated to XHTML 1.1 in 2001, and again it was approved by the W3C membership as a full recommendation. The point is that these recommendations represent more than 6 years of the W3C recommending an XML basis for the future of the web.
The XForms working group defines an important web technology: the next generation of web forms. The technology became a recommendation in 2003 and had a significant refinement earlier this year. Again, XForms has been approved by the W3C membership.
One reason behind the strength of the XForms community is its broad applicability as a web technology. XForms defines the core XML data processing asset, whether the data processing needs be simple or complex. It is designed to be connected to numerous host languages like XHTML, SVG, Voice XML, XSL-FO and even XML vocabularies like XFDL (the one used on Workplace Forms to provide a secure, high-precision presentation for XForms).
The point is that the web is more than just what web browser makers implement. Part of the reason for this is that web browser makers don't tend to make much money on web browsers, so their desire to pour development dollars into their proper maintenance is stunted. As a result, web technologies have flourished from numerous third parties who are helping to define the future nature of web content. Frankly, the browser makers so this coming and created the notion of a plugin precisely to allow web technologies to flourish without their having to do all the work. Really, it's analogous in that respect to open source.
I think the W3C has somewhat lost sight of these facts recently. There appears to be some fear that browser maker lag in implementing some of the recommendations equates with the W3C not "leading the web to its full potential." I respectfully disagree. The situation is not nearly so black and white. The web is supposed to work this way. The web cannot afford to be constrained to the limitations of a browser maker hegemony, especially when they don't even really want the job and have given us the tools to catch our own fish, so to speak.
This brings us to the topic of the recent escalation of Web Forms 2.0 from a member submission by a web browser maker to a first public working draft. The original W3C Team acknowledgement strongly encouraged that the work of accounting for the member submission be placed squarely in the new charters of the XForms and HTML working groups. I can only conjecture that its publication as a working draft of the WAF WG was designed to make sure that the issues raised by Web Forms 2.0 do get addressed, and right soon.
Don't get me wrong. Web Forms 2.0 has some good ease-of-authoring features. By ease-of-authoring I do also mean to imply a smoother migration path for existing HTML-based web content. Members of the XForms working group have been tracking the development of this document, and it turns out to be not too difficult to accommodate the most critical features. However, there are features of Web Forms 2.0, like the repeat construct, which diverge from the conceptual model of XForms for no apparent reason. I would expect that such divergences would be replaced by the XForms basis in the future. One aspect of Web Forms 2.0 that does need the most work is that it really is asking the W3C to take a giant 6 or 8 year leap backward away from an XML basis for web content. This seems a less viable demand, esp. since tag soup HTML UAs are perfectly capable of recognizing markup that isn't ill-formed!
In general, it is true that ease of browser implementation of new features is one important concern, but IBM believes that there are many important factors that contribute not only to the total cost of ownership of web applications but also to the ability to create and maintain a significantly broader spectrum of current and future web technologies. IBM believes that these factors are important enough that it is essential to use new features of HTML as an enticement toward greater conformance of web content to XML syntax. Moreover, IBM strongly advocates for the renewed charter of the XForms and HTML working groups to include unification of the Web Forms 2.0 work with emphases on the ease-of-use benefits from WF2 and the XML basis from XForms. There will be compromises required of all parties, but also significant synergies that become possible by accommodating the full range of forms expertise available in the W3C.
The above are excerpts from the full IBM position statement, which has been posted to the W3C chairs list, the W3C AC Forum, and the public lists of the XForms, HTML and Web Application Formats working groups. See the XForms posting and the WAF WG posting.
In conclusion, I do not by any means want to constrain XForms to only one host language (XHTML). However, I also do not want to downplay the importance of the XHTML host language in helping to bring the great technology that XForms is to the people. The XForms working group is committed to a unification of the best that the Web Forms 2.0 has to offer. We already have a decent implicit data generation feature, and we look forward to expanding that to implicit data model generation so that the easier
on the glass authoring experience can be provided while still allowing the XHTML and XForms standards to scale up to the needs of larger web applications. It really will be the best of both worlds, so please do what you can to communicate to your W3C AC Reps that this is the way to go!
On a recent ad for a movie or TV program, I heard an irreverent but nonetheless funny line about there being no team in I. Good for a laugh, but it did remind me of that more deeply satisfying idiomatic saying: There is no 'I' in team. As well, it reminded me that I wanted to say a thing or two more about a recent interview I did with Jonathan Erickson for the Dr. Dobb's Journal Developer's Diary.
The purpose of the diary is to provide snapshots in the lives of real developers at various stages of their careers to find out what they do, what makes life harder for them, and what makes their job easier. I was honored to be selected, and Dr. Dobb's did a good job of relating what I said. If you read the print version, you'll see that they said 'Turing incomplete' instead of 'Turing complete' but that was immediately corrected in the online version. But the main thing I wanted to talk to you about was the question of what makes my job easier because I talked about two things, but they only had space for one.
In response to the question of what makes my life easier, I would say that I see my job as a senior technical leader being comprised of both challenging problems to work on as well as interesting people to work with. On the problem-solving side, I made mention of the important role that algorithm analysis has played in not only effective problem-solving, but in seeing where the problems really are and how to either solve or sidestep them as needed. However, I'd like to at least make public my thoughts on the people side of my role, too.
Specifically, I would like to call your attention to the Workplace Forms team and the XForms community. Whether I am directly participant in a collaboration or simply observing the members of either group, I have to say that the level of dedication you demonstrate inspires me. You, the people, certainly give meaning to my own work, and I am proud to be working with you to build Workplace Forms and XForms.
A few posts ago I promised to get back around to the discussion of the namespace and versioning of XForms 1.1.
In the early days of XForms 1.1 (late 2004), we expected to upgrade the namespace URI as the means of indicating which processor should be used to interpret the XForms vocabulary within a document. There were, after all, not just new elements but also new attributes for existing elements and in some cases slightly adjusted behaviors for the same elements.
Well, a lot can happen in 18 months! For one thing, we originally intended to publish XForms 1.1 as the upgrade to XForms 1.0, but since then we decided to focus more heavily on the excellence of XForms 1.0, resulting in the publication of a significant body of errata. Those have since appeared in the new W3C Recommendation for XForms 1.0 in March of 2006. We have since published some further errata, and I expect we will publish an updated errata list in the next few weeks. This has allowed XForms 1.1 to become much more about the new features and less about the behaviors of existing features.
The second thing that change is that we decided that an important aspect of increasing XForms adoption was to make it easier for web content authors to write. For this reason, the HTML working group communicated the need to import the XForms module directly into the XHTML2 namespace rather than leaving it in the native XForms namespace. To accommodate this requirement, we created the notion of a chameleon namespace in the schema for XForms 1.1. This concept allows us to define XForms in the XForms namespace, but it allows a host language like XHTML to more easily import the XForms vocabulary by substituting its own namespace instead of the default XForms namespace.
Of course, any host language that attempts such an import has to deal with possible name conflicts, and we did encounter some, like the src attribute. We had to do some jiggling of both XHTML2 and XForms to smooth the integration. This is interesting to note because you can't expect XForms to change for every host language. We did this more as a one-off for XHTML to help increase adoption. Generally, XForms remaining in the XForms namespace is preferrable because it is easier for a wider array of XML-based tools (like XSLT) to find the XForms content if it stays in its own namespace. However, there is a special heritage for web content, so adding the chameleon namespace to XForms and making other technical adjustments was part of our effort to cater to backward compatibility needs and ease of authoring needs.
So, to be clear, XForms content should remain in the XForms namespace whenever possible, such as when used with host languages other than XHTML, because there are significant technical benefits to doing so.
Now, how does this relate to the versionining of XForms or the fact that XForms 1.1 will use the same namespaces as XForms 1.0? Well, along separate lines, the XForms working group had received a number of communiques indicating that the change of namespace made it harder to write software that processed XForms content in ways that were not necessarily affected the vocabulary changes. Basically, the change of namespace was viewed as costly to the community. While mulling over this feedback several months ago, I realized that people who were dissatisfied with our change of namespace URI between XForms 1.0 to XForms 1.1 could simply use the chameleon namespace feature to put the XForms 1.1 markup into the XForms 1.0 namespace. They didn't have to use the feature to put the markup in the namespace of a host language.
This thought was very good news for solving the problem of those who wanted us not to change the namespace of XForms in 1.1. Since the chameleon namespace feature could defeat the intent to use the namespace URI to control the language version, clearly we had to change to versioning 'within' the XForms vocabulary. Hence, you can see in the latest working draft of XForms 1.1 that we now have reverted to the one and only XForms namespace URI originally allocated in 2002, and we have added an internal version attribute on the XForms model, defaulting to 1.0, to indicate the version of the language.
I'd like to make this extra posting this week to draw your attention to a series of excellent articles recently completed by Kurt Cagle. The series is entitled Understanding XForms and consists of the following entries:
- Why XForms Matter, Revisited
- The Model
- Events and Actions
- AJAX, XBL and XForms.org
These articles give a lot of information about the value proposition of XForms to projects, and they're worth your time.
There's a new movie due out soon with a really cool name (Snakes on a Plane) and starring an actor I like, Samuel Jackson. Josh Friedman was supposed to help edit the screenplay, but he walked when studio execs threatened to change the name to something banal. However, Sam apparently signed up for the movie because of the name, so it had to stay. Anyway, Josh blogged about months ago, and since then the movie itself has taken on this kind of Web 2.0 existence where the people's conjectures about the movie's content have actually caused the studios to adapt the movie!
Aside from changing the actual film content, the fan base (surreal as that sounds) have actually been responsible for creating marketing hype, movie paraphernalia and even an internet meme for the title. Apparently, Snakes on a Plane is now synonymous "That's Life!" or my personal favorite way of saying the same ("Shh! It happens.") An example from everyday life might be
Programmer on Friday afternoon: "I was going to be done by code module today, but such-and-such didn't properly implement the standard, so now I have to work around their bug."
Hip Manager: "Snakes on a plane. What time did you say you'd be in tomorrow?"
Neat but what's this got to do with Workplace Forms, you say. Well, it's really good to know background cultural information no matter what. Background information is always good to have around. Take for example, an exciting new extension I've recently heard that someone has built for the Workplace Forms Designer. It allows a form author to select a group of form controls, it then figures out the associated markup, and allows the form author to indicate how many times to iterate that markup. Makes creating tables a snap!
Snakes on a plane! Here we are talking about all the cool new features that will be coming in the future of XForms, and the background cultural information that clearly needs further socialization is that
- Workplace Forms includes XForms
- XForms contains a repeat element
- It repeats a given set of controls according to any limits. You could have any number of rows of controls needed to fit your data, though for speed and ease of use we usually recommend keeping a table within a page.
- The design experience is that you just write the table template. No design time duplication of markup.
That last point is really important. Suppose you have some popup selection control that you need duplicated 15 times. Then you decide it needs to have another selection. If you use an XForms repeat, you only have to change the one selection control in the repeat template. If you duplicated controls at design time, then you would have 15 changes to make.
But, hey, at least when the customer asks how to write more maintainable tables, we already have an answer.
Well, I haven't blogged for the last couple of weeks because, as it turns out, I was swimming with the sharks!
Well, actually, I tried my best not to be in the water when a pair of hammerheads and a trio of grays came callin', but one morning my wife and I had to rush into the water to help an older man who was merrily floating along, ears below the water line and a pair of hammerhead fins vectoring his way.
Otherwise, a peaceful and restful vacation and back in the XForms saddle. And while I was away, the W3C publication process did indeed unfold as expected (with a little help from Steven Pemberton) to allow delivery of the latest working draft of XForms 1.1
Notice that the above link takes you to the diff-marked version of the spec. These show the differences between the current working draft and its predecessor, which was published in December of 2005. If you have familiarity with the prior spec, this allows you to see the new things that have made it into XForms 1.1, and the changes to existing features of XForms 1.1
There are quite a few smaller tweaks here and there, but I'll focus a bit here on the big ticket items. One is the effort the XForms team has been putting into the access that XForms authors will have to event context information in XForms actions. This is going to be a very powerful addition to the language. The other major area of change involves the addition of features to the XForms submission module. The goal of these changes is to open up XForms to a wider variety of sympathetic web technologies. Frankly, there is an interplay between the changes we made to submission and to event context. Expect some further changes and additions in the next working draft.
A small change that has, perhaps, the most important and far-reaching implications is the namespace URI that will be used for XForms 1.1. This is a very challenging issue, but the net is that XForms 1.1 will use the same namespace URI as XForms 1.0. Like those sharks, this really bites in some ways, but also like the sharks, it turns out to be unavoidable. Stay tuned, and I'll tell you why in an upcoming blog entry.
I have a three items of interest for you today.
First, I've updated the wikipedia entry for XForms. It now mentions the IBM Workplace Forms implementation in appropriate places. I also updated it to make the intro more understandable and to draw attention to the Ajax-like behavior of XForms instance replacement submissions. I also added a few more external links, including links to XForms-related blogs (including this one, of course).
Second, in its ongoing effort to refine the technical precision of XForms, the working group today published a collection of errata for XForms 1.0 Second Edition. In my view, the three most important are
- The new description of the type model item property, which is used to assign datatypes, whether defined by simple type or complex type with simple content. The type MIP is not used to associate a complex type to an instance node with element children.
- The new description of deferred update behavior of XForms actions.
- The clarification to recalculation, which is useful to ensuring that a node can be assigned a default value using a calculate formula and a readonly setting of false.
The working group currently plans to publish further errata for XForms 1.0 Second Edition in August.
And thirdly, the working group today initiated the publication of an update XForms 1.1 working draft, which should appear by the end of the week. This will be the second to last "thin" spec (a spec describing only new features). We expect to publish one more thin spec near the end of August, then we will migrate to a full spec by merging XForms 1.0, the errata, and the new features in the thin spec.
Continuing with the last blog, you saw autotabbing at work, and clearly three XForms controls were working together to collect some common data. But here we're going to refine the aggregation of the controls in both the user interface and the model layers.
For starters, suppose a larger example in which the phone number being collected is not the only piece of data, but rather is nested deep within a larger XML data structure:
<xforms:instance xmlns="" id="X"> <data> ... <customer> ... <phone> <areaCode/> <exchange/> <local/> </phone> ... </customer> ... </data></xforms:instance>
In the prior user interface, the three input controls relied on the fact that the default evaluation context for user interface bindings is the root element node of the instance. Even though the
phone element is no longer the root element above, we can keep the same input controls by setting the context using an XForms
group to more properly communicate the intent to combine these controls together in the user interface layer:
<xforms:group ref="customer/phone"> <xforms:input ref="areaCode" incremental="true" id="areaCode"> <xforms:label>Area Code</xforms:label> ... </xforms:input>
<xforms:input ref="exchange" incremental="true" id="exchange"> <xforms:label>Exchange:</xforms:label> ... </xforms:input>
<xforms:input ref="local" incremental="true" id="local"> <xforms:label>Local:</xforms:label> ... </xforms:input></xforms:group>
The second thing you may want to do is to combine the three components of the phone number together into a single result. There are quite a few ways to do this, so here we'll just pick a simple way and run with it. Say, you were to add an attribute called
number to the
phone element, like so:
<xforms:instance xmlns="" id="X"> <data> ... <customer> ... <phone number="2505551212"> <areaCode>250</areaCode> <exchange>555</exchange> <local>1212</local> </phone> ... </customer> ... </data></xforms:instance>
It's then an easy matter to combine the three phone number components together to form the full result using an XForms calculate formula:
<xforms:bind nodeset="customer/phone/@number" calculate="concat(../areaCode, ../exchange, ../local)"/>
Someone wrote me recently asking how they could aggregate a number of form controls together to achieve a common purpose.
Sidebar: It is legal to use the word they as a singular pronoun. And not just when the answer to the question he/she or s/he asked is applicable to a plurality of people, it can be used at any time to avoid those horrible slashing language kludges. Still, I have to admit it's easier on the ear when the answer applies to many.
Of course, the answer to the above question applies to many! I'll use the syntax of pure XForms as a pseudo-code for your visual experience in the Workplace Forms designer, where you can add whatever presentational beautification seems appropriate. So, let's say you want to aggregate the input controls to collect the parts of a phone number. Since forms are often written per locale, I'll focus on the North American format, since the same idea applies to other formats. The format consists of a 3 digit area code, a 3 digit exchange and a 4 digit local. So your instance data would look something like this:
<xforms:instance xmlns="" id="X"> <phone> <areaCode/> <exchange/> <local/> </phone></xforms:instance>
Now you'd hook up input controls to allow the user to enter data for each of these parts. We'll talk about the elided part of each control in a moment:
<xforms:input ref="areaCode" incremental="true" id="areaCode"> <xforms:label>Area Code</xforms:label> ...</xforms:input>
<xforms:input ref="exchange" incremental="true" id="exchange"> <xforms:label>Exchange:</xforms:label> ...</xforms:input>
<xforms:input ref="local" incremental="true" id="local"> <xforms:label>Local:</xforms:label> ...</xforms:input>
The automatic tabbing feature begins with the
incremental attribute. By default, an
xforms:input allows the user to type any number of characters without changing the XML data to which the control is bound until the user indicates that the value should be committed (by hitting tab or changing the input focus). This is the
false setting for
incremental, which is the default. But if you set it to
true, then the bound XML instance data node is changed on every keystroke.
Every time you change the data associated with an XForms form control, the control receives an
xforms-value-changed event. This means that an XForms action can be created to listen for that event and perform a behavior when it happens. Like, say for example, change the focus if the user types 3 digits. In XForms 1.1, you will be able to write the area code input as follows:
<xforms:input ref="areaCode" incremental="true" id="areaCode"> <xforms:label>Area Code</xforms:label> <xforms:setfocus ev:event="xforms-value-changed" control="exchange" if="string-length(.)=3 and . >= 0"/></xforms:input>
ev:event attribute says that the
xforms:setfocus action is a handler for the
xforms-value-changed event. The form control to which the focus will be sent is the one with
id="exchange", and this will occur only if the current context node contains three characters and evaluates to a number greater than or equal to zero. The current node is of course
areaCode, and in XPath you signify the current node using a period, which is very familiar to many because it is the same notation as is used for the current directory on a file system.
OK, all of this is simple enough, but why did I use the future tense. The reason is that XForms 1.1 is a working draft. XForms 1.0 is the recommendation, so what can you do now. Well, for all of its elements, XForms 1.0 defines the "Common Attributes" bundle as including any foreign namespaced attributes. This was done to allow host languages (like XFDL for Workplace Forms) to be able to add their own enhancements in advance of the recommendations to meet pressing business needs and also to experiment with the best ways of adding new features to the XForms language. In this case, the need for conditional execution of an action is clearly needed, and it's pretty much a done deal that the
if attribute will be in the XForms 1.1 when it becomes a recommendation. So, in Workplace Forms you can use the conditional attribute today, only it has to be in the XFDL namespace, so you would simply adjust the
xforms:setfocus handler as follows:
<xforms:input ref="areaCode" incremental="true" id="areaCode"> <xforms:label>Area Code</xforms:label> <xforms:setfocus ev:event="xforms-value-changed" control="exchange" xfdl:if="string-length(.)=3 and . >= 0"/></xforms:input>
That's all folks!
Now you can get free access to the trial versions of IBM Workplace Forms software. The trial software includes the Eclipse-based visual design environment as well as the rich client viewer (a desktop application and web browser plugin). The suite includes a server component that delivers the form viewing and rich user experience with a zero footprint on the client (using the existing web browser only with no client-side install). However, the server product is not part of the trial software.
Workplace Forms supports development and deployment of XML forms and XForms-based XML forms in the following languages: Chinese Simplified, Chinese Traditional, Croatian, Czech, Danish, Dutch, English International, Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese Brazilian, Romanian, Russian, Slovakian, Slovenian, Spanish, Swedish, and Turkish.
One final note is that in order to get the trial software, you have to get an IBM developerworks ID. But that's free and easy to do, and the benefits immediately begin with access to the most powerful, advanced, pure XML electronic forms system on the market today.
In the final day of the XForms face-to-face meeting today, we made great progress for XForms 1.1 defining synchronous or asynchronous submission.
A number of current implementations of XForms 1.0 perform instance data relevance pruning and validation followed by initiation of the data submission. The upload and download of octets occurs asynchronously, and when completed, the xforms-submit-done or xforms-submit-error is dispatched. However, the current recommendations for (DOM2) XML events and XForms actually describe a synchronous procession that starts with dispatching an xforms-submit through fives steps of default processing from relevance pruning and data validation all the way through to completion and dispatch of xforms-submit-done or xforms-submit-error.
A difference of behavior occurs when an action sequence contains a
send action followed by other actions. If the submission is synchronous, then the form author can expect that the actions after the send are able to operate over the data returned by the submission. For an asynchronous implementation, the send action returns before the new data arrives.
In reality, form authors should put the follow-on actions after a send into a handler for the xforms-submit-done event, since actions over data should only be run if the submission succeeds. Still, what's a working group to do?
We'll be adding a new attribute, probably called mode and probably having the value synchronous or asynchronous, so that the form author can choose which behavior is best. The synchronous behavior will have other advantages like suspending user interaction with form controls, but the default will undoubtedly be asynchronous.
Meanwhile, XForms 1.0 authors, get into the habit now of putting actions that operate over submission response data into the xforms-submit-done handler, not after a send action.
I got a note from Eric Bruchez reminding me to comment that XForms 1.1 will also make available submission response header information in the xforms-submit-done event context, which helps complete the story about ATOM.
Yesterday was also a really good day in which we worked out some challenging issues related to the XForms
type model item property.
One reason this was important was for ensuring that we had a proper answer for the last technical question about XForms basic. We confirmed it was not an issue for basic, so you can expect to see basic progress through the rest of the W3C process RSN (real soon now).
We also came to agreement on the meaning of the
type MIP in two interesting scenarios. When an element has an attribute but only simple content, technically it is still a complexType according to W3C schema. So, what happens when
type refers to a simpleType? Also, is a form author allowed to refer to a complexType with simpleContent using XForms type, and if so, does it validate the node or just the content?
And the answers are... the
type MIP applies only to the validation of the string-value of nodes that have no element children, i.e. it only validates content and only when the content is character data. If a simpleType is used on an element with an attribute, that's OK because the simpleType will only be used to validate the element's content. And if a complexType with simpleContent is applied to an element node, only the element content will be validated according to the underlying simpleType. This means that if the attribute on the element node is invalid according to the complexType, the element itself would not be flagged as invalid.
This is a reasaonably nice synchronization of what a user can modify via user interface bindings, what a calculate can modify, and what the type MIP actually validates.
We've been quite busy today in the XForms working group. Our work has been focused on modifications of the functionality of XForms submission for XForms 1.1. Tomorrow we will address any details that come up as the pieces of the spec are put together for the next working draft, but here is an overview:
- We're adding context information to the xforms-submit-done event so that an XForm can access the http return code.
- We're adding support for the DELETE method, which is more reasonable can be done now that the return code will be available. One practical result of this is that you will be able to write an XForms that speaks ATOM.
- We're allowing run-time modification of the submission URL. We'll be adding a child element called
resource to the submission element, and it will be able to use a single-node binding or value attribute to construct a URL that includes data from an XForms instance.
- We're allowing the ability to set content headers for the submission so that, among other things, an XForm can speak WebDAV. We'll be adding a child element called
header that will take a name attribute as well as single-node binding, value attribute, or content for the value of the header. You will be able to put as many headers as you want. The main detail to be fleshed out is out to say that user agents/XForms processors may choose to ignore some of the header settings.
- We're updating the context information available to xforms-submit-error so that XForms authors will be able to determine whether the submission failed due to a validation error versus an error resolving the URL.
Tomorrow we will be discussing aspects of the XForms type model item property. I'm anxiously awaiting the outcome because, frankly, I've been waiting a few weeks now to tell you about these aspects, but I need the group resolutions to occur before posting my comments. I think it will turn out well, though!
Since I couldn't put it better myself, let me quote from an email today from John Schumacher, our Development Director for Content Management Applications for Websphere Portal, Workplace and Domino:
"Please join me in congratulating the WorkPlace Forms team. This morning, on schedule, WorkPlace Forms 2.6 was made available for eGA on passport and is also available for download internally on Extreme Leverage!!!! I have already downloaded my copy. Keith MacKenzie and his team have done a tremendous job staying focused on the delivery of this major release ... The Forms products are now Internationalized to help support world wide sales, provides market leading support for the XForms standard which differentiates us from our proprietary competitors... and has aligned our development tool story with the rest of the IBM."
I am very pleased personally that we have been able to create the union of XForms, product globalization, and precision forms technology offered via the XFDL language. It is particularly satisfying this week since the IBM Victoria Software Lab is hosting the XForms face-to-face meeting starting tomorrow. It's always good news to see XForms implementers deriving power, efficiency and overall benefit from XForms, but being able to announce general availability on the first day of the face to face meeting you are hosting... cat to the cream!
And finally, this release and the completion of the XForms face-to-face will open up my ability to talk about more pointy bracketed things on this blog in the coming weeks :-)
Today is an exciting day for the IBM Victoria Software Lab because today we have been pushing the new version of the IBM Workplace Forms product line into the IBM release queue. General availability is on June 13th, but it's on its way folks!
The IBM Workplace Forms product line is designed to simplify the process of creating and maintaining forms-based web applications. The flagship knowledge product of the product line is an XML vocabulary called XFDL, which is an XForms-enabled language that provides a rich and precise presentation layer for XML data. The IBM Workplace Forms software supports the full life cycle of XFDL documents, from creation to run-time to processing of completed form documents.
The IBM Workplace Forms Designer is an eclipse-based visual development environment for creating XFDL documents. It has a main canvas for drag-and-drop design of the user interface. The drag-and-drop palette has all the usual suspects for atomic form controls as well as containment controls like repeat tables and group/switch panes. The user can also add custom groups of controls to the palette as single new controls. This makes it easy to standardize constructs like toolbars or address blocks across all forms in a workspace.
It is no surprise that a form filled with the Viewer and with WebForm Server are indistinguishable to the web application developer. Our intent is to provide a single document paradigm for the form design and the web application development. So, both of our form run-time products are based on a common API that understands and implements much of XFDL. Although the nature of XFDL as an XML vocabulary means that standard XML tools could be used to process XFDL documents, the XFDL API is also made available to the web application developer. The idea is that your servlet/portlet will require less coding if you use an API that understands not just XML, but the XML vocabulary of the document. For this reason, the IBM Workplace Forms Server contains not just the WebForm server, but also the API.
Rounding out the Server product is the IBM Workplace Forms Server - Deployment Server. This server facilitates mass deployment of the Viewer and custom viewer extension files by providing an on-demand install experience that can be customized by the server adminstrator.
We usually think of a document as a file. A file is, at the operating system level, a unit of information. The OS can associate properties with it (like who can read it or write it), and the file can easily be moved from directory to directory or computer to computer with standard tools like FTP, email, or flash drive.
The XML recommendation defines a document as that which conforms to BNF rule #1 of the XML syntax. Of course it is useful if an XML document is the sole content of the unit of information being transferred, i.e. if the XML is the only thing in a file. This is because XML tools tend to be built with programming languages that expose services of the operating system.
However, the most important part of an XML document is capable of being contained within another document. In fact, XML canonicalization strips away the part of an XML document that would prevent the result from appearing as element content.
This is the idea that XForms uses when it expresses XML instance data within a larger document, and specifically within the
<xforms:instance> element. Of course, the
<xforms:instance> element can also reference a whole XML document using the
src attribute, but in both cases, the result is parsed into the live running instance data. The user interacts with the XML data document, and the XML data document is what is returned to the server by an
This paradigm works well enough if you think of a form as an ephemeral view of a back-end database or content repository. However, people find it easier to work with a document in the file sense of the word. we like to save our document, email it, reload it the next day or on a new computer, and especially on a computer that has become disconnected from the net or from the original web application context that would be associated with the ephemeral view kind of form.
Enter the document-centric approach of Workplace Forms, the technological basis of which is an XML document whose element names belong to the XFDL and XForms vocabularies. Moreover, the underlying XML data document is still incorporated by the
<xforms:instance> just like all other XForms-based documents.
A key difference is that being a document implies that the form with eventually have to be re-serialized, e.g. to save or sign the form. XForms doesn't really talk about how to reintegrate the live, modified XML data back into the document, but in truth it's really not that hard. The main technical hiccup on the XForms side is that the
src attribute takes precedence over the content of
<xforms:instance>, so when the live data is synchronized back into the form, the
src attribute has to be eliminated.
The conclusion, though, is that a Workplace Form, or XFDL document, is a cross between an office document and an mobile intelligent agent. It can be saved, reloaded, printed, emailed, archived, signed, submitted to web application and portal servers, and participate in document management, records management and content repository processes. This is how the notion of document makes a form be more than just an ephemeral view of data.
What is the value proposition of an open standard?
XML is fairly pervasive, so we rarely ask this question of XML anymore, but once upon a time the question came up a lot as business managers tried to figure out why the technical people were insisting on spending money to move to XML. And the truth is that the impact is difficult to measure precisely, so open standards are sometimes a bit of an uphill battle. Nevertheless, the software engineering benefits are tangible and increase in magnitude over time.
One benefit is, of course, the human resource factor. Given a schema or DTD for a pile of pointy brackets, human beings can learn a lot about your document format quickly, which means they can become proficient more quickly and be more efficient overall at moving information into and out of the document.
This has an impact on the development of software systems. The software engineering benefits of increased interoperability/looser coupling of system modules have a significant positive effect on the time and cost efficiency of software development. Really, it's the same benefits as a service oriented architecture, which is why SOA and XML documents are such a good match.
But XML standardization has a deeper impact as it also places a value on the document format. In other words, the document format becomes a product in and of itself. A software system based on an XML document format is more valuable than one that is not because it is easier for enterprises to migrate to or from the document format. The benefit to a vendor of enterprises being able to migrate to the vendor's format is immediately obvious, but the ability of the enterprise to migrate from the vendor's format is also surprisingly valuable to the vendor. This is true not just for the obvious reason that being trapped in a document format is inherently costly to an enterprise. So, the enterprise can more readily adopt a vendor's solution when it does not imply vendor lock-in, but frankly it is the capability to more easily migrate away from the vendor's solution that becomes a selling point. A vendor can say, "We know you have a choice, so we're going to be responsive to your needs and deliver quality software so you keep choosing us."
It is with all these benefits in mind that we moved the predecessor of Workplace Forms to an XML syntax called XFDL. The XFDL language is an XML vocabulary that simplifies the design, development and deployment of high precision, secure forms applications that provide a rich user experience.
Of course, the first thing we did with our new XML syntax was to report it to the W3C in a document which became a W3C Note. The purpose of a W3C Note is to bring to the attention of the W3C something that contains aspects worth of consideration for standardization. The W3C does not and never will standardize a vendor's submission. But it does take note of its own notes! A positively reviewed note is likely to result in some movement in the standardization world. In the case of XFDL, that movement has occurred all over the place, including the likes of XPath, XML Schema, XML Signatures and Canonicalization, and XForms.
Of course, XFDL now incorporates XForms to express all aspects of XFDL that it can. And like a good standard ought to do, XForms itself incorporates other W3C technologies where appropriate, like XPath and XML Schema. But XForms depends on a host language to deliver the actual user experience, and there are aspects of a precision presentation and rich user experience that properly belong at the host language level. And XFDL even encodes these bits with the most pervasive standard of all -- XML.
I am the happy owner of an excellent new book entitled "Document Engineering" by Robert Glushko and Tim McGrath. The reader goes on journey through many of the XML technologies that are brought to bear to solve business informatics problems. The journey does not jostle and stab with so many pointy brackets, but rather focuses intently on why we need all of these technologies and how to put them together sensibly.
There are so many nuggets of wisdom in the book that of course I cannot tell you all about it in this blog. Just like the Matrix, you have to see it for yourself! But I would be remiss in not giving you at least a taste, especially since the message is so closely aligned to the value proposition of XForms and, indeed, XFDL+XForms.
- Documents describe the interfaces to business processes. (Ch. 1)
- Loose coupling is necessary for integration across enterprise boundaries... (Ch. 4)
- Service oriented architecture is a design philosophy; web services are a set of standards and techniques. (Ch. 4)
In other words, XML documents are the lifeblood of a service oriented architecture, and XML technologies are valuable because they help us overcome the limitations of rigid, monolithic systems.
With Workplace Forms, we combine XFDL and XForms to achieve a somewhat elaborated version of this view in which the forms themselves are the documents that make their way through a service oriented architecture, interacting according to their own rules of engagement to achieve validity of the contained XML data document and more efficiently achieve the intent of a business process.
In other words, the SOA is the infrastructure, the XFDL form is the medium, and the XML data is the message. With this analogy, it is easy to see that the powerful words of Marshall McLuhan are applicable: The medium is the message. The more powerful the medium, the more powerful the message. An XForms layer around XML data trumps a system in which only the XML data is standardized. An XFDL layer around the XForm... transaction auditability, digital signature security, comprehensive accessibility, rich text, globalization, and on and on. All the things we get to talk about in future installments of this blog.
An interesting comment showed up on my prior post that seemed worth discussing as part of getting around to talking about what XFDL does for (and with) XForms.
In the last post, I talked about what XForms does and what it doesn't do from the big picture perspective. XForms does seek to standardize the language for the core information processing asset expressed within a form. XForms does not seek to standardize the exact presentation of a user interface. XForms delegates this task to different XML host languages like XHTML or XFDL (or others in the future like, hopefully, VoiceXML). These host languages exist to satisfy different requirements that exist beyond the core information processing requirements, but XForms allow us to design the underlying application once and handle presentment and other orthogonal requirements as the separate issues that they are.
The comment came in saying that one thing XForms doesn't do is allow the URL of a submission to be dynamically calculated. This is a technical limitation that does not affect the big picture of what we're trying to achieve with XForms. The XForms language does contain some technical limitations like this. Many of them are being addressed in XForms 1.1. This issue in particular should be addressed in the very next working draft of XForms 1.1.
However, because we have to deliver products that can be used to build applications now, it sometimes happens that implementations have to lead the standard with custom extensions until the standard comes along and specifies the common way that everyone on the working group agrees is the way the language will express a feature.
In XFDL, we make relatively few changes to XForms because we want our documents to be as conformant as possible. However, this particular issue of a dynamic URL comes up in almost all of the forms applications we have every deployed, so we did not feel we could make our next release of Workplace Forms without some ability to do a dynamic URL on an XForms submission. At the same time, we do like it to be clear to the form author when an extension is being used. As a result, the addition was made using an attribute in the XFDL namespace. This makes it easier to find those bits of our XForms-based documents that will need special attention when trying to get them to interoperate with other XForms implementations.
In the upcoming release of Workplace Forms, you can create XForms-based applications that include a dynamic URL component by using an
xfdl:actionref attribute instead of an
action in the
xforms:submission. The content of
xfdl:actionref is an XPath expression whose result is the node containing the desired URL. Of course, the full power of XForms calculations can be brought to bear on that node to allow dynamic calculation of all or any portion of the final URL.
In XForms 1.1, I am expecting a more general mechanism that will allow the instance data to be used to set not just the URL, but eventually many of the other parameters too.
The purpose of XForms is to express the core XML data processing asset used in sophisticated data collection scenarios.
In fact, it would be better if XForms were called the XML data processing language (XDP or XDPL) because XML is about standardizing data and about 80% of business transactions are based on filling out some kind of form to collect the transactional data.
An XForm contains one or more XML data instances. An instance is an arbitrarily structured XML data document that is typically an instance of some XML schema that expresses the static validation rules for a target namespace.
One can write an XForm without an XML schema by just expressing the XML data in an instance. This is because XForms provides other channels of data validity checking that can be easier to work with when only simple data type validation is needed. For example, you can use an XForms
type declaration to associate an
xsd:date or similar data type to an XML data node without writing an XML schema for your XForm.
But XForms validity checking is also dynamic, in recognition of the fact that validity of some values can be based on other values or the aggregation of other values. For example, in an interlibrary article request, the upper bound page number in the journal must not be less than the lower bound page number. Or, the user is only authorized to make a purchase order with less than $10,000 total value.
The latter example is important because it leads to the conclusion that we not only need a way of testing data values relative to other data values, but also that we need a way of calculating data values that are then used in validity tests.
From there, it is not a big leap to conclude that generalized XML data processing requires some way to indicate dynamically whether further changes should be allowed to certain pieces of data or whether certain parts of the data are still applicable to the transaction based on other data values. A good example is a mortgage preapproval form that can handle both single and joint applications. The co-applicant data is only relevant if the user selects the joint application mode.
XForms allows the form author to express formulae for these aspects of data, which are called model item properties, or just MIPs. Not too surprisingly, the names of these MIPs are
Of course, there is no point in representing data, calculating values over data, and validating data if you have no way to change the data. XForms allows simple content data values to be changed, but it also allows insertion and deletion of larger blocks of data that contain internal structure because this is essentially what's needed to add or delete a row from a table.
Most importantly, XForms offers form controls that expose data to the surrounding application context. If the data changes, the form controls change. This includes not only exposing a changed simple content data value, but if a set of form controls are associated with a repeated sequence of structured data, and the number of data nodes in the sequence changes, then form controls are created or destroyed as needed to respond to the change of data.
XForms is all about thinking of the data first and driving outward to how that data gets exposed to applications. Perhaps the most prevalent of such applications are for presenting the data to a human user, though even human users have highly varied capabilities. For example, the desktop user and the PDA user have very different visual capabilities. Of course, this argument extends easily to meeting the far greater accessibility needs of the sight-impaired.
For this reason, the XForms form controls represent what I've often called an intent-based user interface. It's kind of neat to see the term popping up more frequently now. It gets to the heart of the matter: XForms does not provide a presentation layer. XForms relies for presentation on a host language like XFDL (in Workplace Forms) or XHTML (in web browsers). I am certainly hoping that VoiceXML will come to the conclusion that they should soak up the benefits of XForms rather than reinventing all of this stuff over again (partly because almost everybody underestimates how much work goes into it until it's too late; but maybe they will prove to be wiser than the rest).
I sometimes get asked whether XForms will next extend itself to standardizing the actual presentation layer. Clearly, from above the answer is no. XForms standardizes the core XML data processing asset, and more work will go into doing a better job of that. The key issue we want is to address interoperability and reusability across applications and user contexts of the data processing behaviors that are fundamental to completing a transaction.
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.
IBM is interested in all manner of open standards, including XForms, because they allow organizations to express their information assets in a format that can more easily be preserved as one incorporates more technologies into an application over time to meet evolving business requirements.
As Kevin Kelley (STSM, emerging standards) explained in a telecon this morning, the standards are like an on-ramp that allows assets to be developed over time. If you care about reuse of those assets, then you care about standards.
To be honest, this is the same argument that drove XML to the ubiquity it currently enjoys. With XML, we sought to standardize how data models are expressed. With XForms, we seek to standardize the expression of processing models over that data.
Some upcoming posts:
1) What does XForms actually offer?
2) How does XFDL fit into the above open standards story?
3) What makes XFDL+XForms an ideal format for archival, transaction auditabilty, and transaction security purposes?
Continuing from the last post, here is a reasonable use case for having a global (namespace qualified) attribute with the same local name as a local (unqualified) attribute, where the attributes do not have the same meaning and the global attribute is in the same namespace as the containing element.
The current version of XML Events allows you to declare a listener for an event on a node. There are multiple ways to do this, but the easiest is to use a global attribute in the events namespace (signified by the prefix ev below):
<xforms:action ev:event="DOMActivate"> ...
An xforms:trigger can be represented, for example, by a button widget, and pressing the button results in a DOMActivate event on the trigger.
The ev:event declares the name of the event to listen for, and the default value for ev:target (when it's not specified) is the parent
element of the one containing the ev:event. So, the above declaration causes a listener to be created for the occurrence of the DOMActivate on the trigger. The handler for the event is given by the content of the xforms:action that bears the ev:event. An example of an action to be performed would be inserting a node of data (which would likely correspond to adding a row to a repeat table).
All of this is just plain vanilla XForms so far. But at the W3C tech plenary, the XHTML working group began discussing upgrades to XML events. The reason is that the current version of XML events declares listeners that are created at the moment when the DOM node being listened to is created. There's no way to create a listener later in the life time of a document, possibly contingent on some condition or the occurrence of some event.
Syntax for this could
look something like this:
target="X" event="Y" ...
In this example, ev:listener is an action handler for the DOMActivate event that happens on the trigger. So when you activate the trigger (press the button), a listener for event Y is created on the node with id="X".
The local, namespace unqualified attribute 'event' tells the event that the listener will listen for. The global, namespace qualified event 'ev:event' tells the event whose occurrence causes the ev:listener action to be performed.
This is a very neat and compelling example where a local attribute (event) which is given meaning by a namespace (XML Events) might legitimately have a completely different meaning than a global attribute with the same local name and same namespace as the containing element (ev:event).
Although the XHTML working group quite liked this solution, they had a lengthy discussiona and concluded that this aspect of XML namespaces is not understood well enough to rely on the feature without confusing document authors. Of course, they are free to change their minds later, I would say that the above syntax is not likely to see the light of day in a W3C recommendation.
That's why I'm blogging it. Because even if it goes away, we still need to try to increase understanding of this aspect of namespaces and attributes, and nothing does that better than a good example, and this is the first one I've seen.
And we can thank Steven Pemberton for it![Read More
Well, no blogs from me next week, so seems a good idea to knock off another one this week...
XML namespaces rec (pardon the pun) states that an attribute which is namespace unqualified
is 'local' to an element and is uniquely identified by a combination of the attribute local name and the type and namespace URI of the containing element.
The word identify
really should be used more sparingly, as here is a case where its misuse has caused years of confusion and acrimony in the XML community. An identifier is something that established the identity of something else. You cannot have two things associated with the same identifier unless they are identical things.
I am often frustrated by seasoned W3C folks who say that "this depends on your definition of identify" and honestly
believe this is a defense of the confusion in the namespaces rec. This is like saying ot me, "Well you're right unless you have a definition for identify that doesn't identify things, which is what we
did at the W3C."
To see the problem, you have to look earlier in the spec where a namespace n1 is associated with a URI and then the following code appears:
<good a="1" n1:a="2" />
The problem is that the element 'good' is in the same namespace as n1. So now you have local attribute a
that is essentially given meaning by an element that is in the same namespaces as the 'global' attribute n1:a
. Yes the two attributes have different values.
From this we have to infer that, although a local attribute is given meaning based on the containing element and its namespace, a global attribute with the same local name and namespace qualified into the same namespace can actually mean something totally different.
In other words, we have two attributes with the same local name, contained by the same element, and given meaning by the same namespace URI, but they are not identical. This is the local attribute not
being 'identified' (in my sense) by local name and containing element type and namespace.
The technically subtle W3Cer will tell you that there was no reason to spell out using words in the normative part of the spec the fact that the two attributes are different things because the spec says that local attributes are in a different partition than global ones. Problem is, this partitioning info is in a non-normative part of the spec, and particularly in the same part that has the language about how local attributes are 'identified' by local name and containing element type and namespace.
Anyway, the upshot is that an XML vocabulary does not need to but is allowed to say that local and global attributes with the same local name can mean different things. If they're supposed to mean the same thing, then the XML language has to define a precedence rule for what happens if the two attributes differ in value. Here's an example:
<data xmlns="http://example.org" xmlns:ex="http://example.org">
<price currency="USD" ex:currency="EUR">10</price>
Question: Is the price in USD or Euros?
Answer: Depends on who designed the language.
Second answer: Don't do that.
Interestingly, the XHTML working group came up with a fascinating example where it is legitimate and sensible to have a global and local attribute with the same local name but completely different meanings. It has to do with the next version of XML events. After hours of discussion, the decision was that they weren't going to do that (second answer above). Not because it's illegal, but because it's too subtle for most XML people.
Well, the XHTML group may change their minds, but even if they don't, the example is really worth understanding because it actually makes sense why you'd want to have the two attributes mean something different. Stay tuned, I'll tell you all about it when I get back...[Read More
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