John Boyer is a Senior Technical Staff Member for IBM Lotus Forms. He has co-authored and edited numerous W3C standards and is currently Chair of the W3C Forms Working Group. In 2001, John earned a Ph.D. in computer science, and he has published numerous journal, conference and professional papers on topics ranging from algorithmics to computer security to XML-related technologies.

Repeat Methodologies in XForms 1.0

The public Forms working group mail list has been getting some traffic recently about a correction we made to XForms 1.0 in the second edition. Under the original recommendation, XForms processors had to take a snapshot of initial instance data before any data is filled in so that the empty version of the data can be used to insert new rows of data into a repeat. This is an idea that looks elegant at first, but it breaks down really quickly.

In language design, it is important to have a balance between the appearance of elegance and elegance in fact. Keep things as simple as possible, but no simpler! The initial data snapshot idea is too simple because it works in some cases, in others it only works with a highly sophisticated implementation, and in some reasonable use cases, the insert simply could not act as specified if the initial data snapshot method is used. For example, if the initial instance data did not contain the prototype because the repeating data is obtained by a submission after the form starts, then the insert would fail.

Due to these difficulties, many processors did not even implement the idea. Instead, they were implementing the insert action by making a copy of the last node in the currently running instance data. To correct the design and reflect the will of the XForms community, the recommendation was amended to say that insert creates a new node by copying the last node of its nodeset.

At the same time, XForms was also corrected to say that insert and delete perform no operation when their nodesets resolve to empty nodeset. It seems obvious to say this because if there are no nodes in the delete nodeset, then there is nothing to delete, and if there are no nodes in the insert nodeset, then you wouldn't know where to put a newly duplicated node even if you had one. However, we decided to explicitly say this so that all implementors would know to check for this condition rather than, say, assume they should fail with a binding exception. The reason is that the no-op behavior actually comes in quite handy in solving the full spectrum of use cases for repeats.

Here is an example. It shows how to manipulate a repeat that starts empty and is allowed to become empty and non-empty during run-time. Like a shopping cart. It starts empty, you add stuff to it, then you change your mind and delete the shopping cart items, and then you choose more stuff to buy.

<!-- Initial instance data contains the prototypical node as the last element -->

<xf:instance xmlns="">
   <cart>
      <item>
          <name/>
          ...
   </cart>
</xf:instance>
...

<!-- repeat omits the prototypical node -->

<xf:repeat nodeset="item[position()!=last()]" id="repeat-cart">
   ...
</xf:repeat>

<!-- Add new row after any current row, but do it in a way that can
     also handle zero rows. -->

<xf:trigger>
   <xf:label>Insert
   <xf:insert ev:event="DOMActivate" nodeset="item" at="index('repeat-cart')+1" position="before"/>
</xf:trigger>

<!-- Delete a row from the repeat. If only the prototypical data remains
     then the nodeset becomes empty and the action has no effect. -->

<xf:trigger>
   <xf:label>Delete
   <xf:delete ev:event="DOMActivate" nodeset="item[position()!=last()]" at="index('repeat-cart')"/>
</xf:trigger>

The above example showed that having the delete action resolve to no-operation when its nodeset is empty is very useful. Now, let's see an example in which it is useful for insert to have no effect on empty nodeset. Suppose that instead of a zero row repeat, you want a repeat that stays at one row. If the user hits delete for that row, then the row stays, but the data is cleared from it.

<xf:trigger>
   <xf:label>Delete
   <xf:action ev:event="DOMActivate">
      <xf:delete nodeset="item[position()!=last()]" at="index('repeat-cart')"/>
      <xf:insert nodeset="item[last()=1]" at="1" position="before"/>
   </xf:action>
</xf:trigger>

Here the delete trigger could be activated a number of times, but it will only deleted down to the last row of data that the repeat is actually showing. When the number of elements drops to just the original prototypical data, further pressing of the Delete trigger produces an empty nodeset, so the prototypical data is not removed. The insert follows that up with a nodeset that resolves to empty unless the only data left is the prototypical data. If there is anything more, the insert has no effect. But when only the prototype is left over, we make a new copy of it, which presents a single empty row of data to the user.

The neat thing here is that the above is a general method in which a constant number of XForms actions achieve the desired result regardless of the schema for the data. The data may have inner sequences that correspond to inner repeats in the UI, and you can still use this method on the nodes bound to the outer repeat because the last row of the outer repeat is deleted no matter how many rows are on its inner repeats, and then the insert puts in place a copy of the prototypical data in which node sequence for the inner repeat is in the initial state.

So, you can create repeats that can start and return to the empty state, create repeats that enforce a one row minimum, you can create repeat/insert/delete constructs that operate correctly regardless of when the data is obtained in the lifecycle of the form, and especially, you can create repeat/insert/delete constructs that operate correctly in the save/reload case (e.g. in the presence of prepopulation data). And you can do it without using special attributes being added to XForms 1.1. You can do it today, right now, in XForms 1.0.

Schema choices, XForms switch, and Data Validity

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 in situ, but rather it should be valid on submission.

On the Use of XML Schema for Normative Contributions to W3C Recommendations

The XML Schema language is a good language for capturing the syntactic constraints of an XML vocabulary. But let's face it, it is really designed more for describing data. It's just not powerful enough to be used for making normative contributions to W3C Recommendations like, say, XForms.

This is not to say that a disagreement between the recommendation and the schema won't sometimes be resolved in favor of what the schema says, but there is a reasonably popular view that the schema is also normative. Actually, the recommendation is normative. In fact, the recommendation is typically provided in two or three formats (sliced up version, single HTML file, diff marked version), and only one of those is considered normative. Even more to the point, English is, for better or worse, the only language in which the normative recommendation is expressed. Any other versions are also considered to be informative.

Quite apart from what anyone tells you about the normativeness of a schema, you can determine that the schema associated with a recommendation is informative, not normative, if it does not appear in TR space. This is a subdirectory of the W3 website named 'tr' and used to publish all technical recommendations of the W3C. In the case of XForms, the schema lives in the working group space, not TR space, so it is informative.

However, the location of the schema isn't really the deciding factor for me. Even if a schema did appear in TR space, it still would only be informative in my opinion because there are lots of language constraints that you just cannot express in schema but which are expressed in the recommendation. A number of great examples of this can be found in XForms, two of which are explained below.

Perhaps the easiest is the use of XPath expressions in XForms. In the XForms schema, a number of the attributes like calculate and ref have values that must be XPath expressions. The schema declaration for those attributes declares a type of xforms:XPathExpression. But here is what the XForms schema defines for the XPathExpression type:

  <xsd:simpleType name="XPathExpression">
    <xsd:restriction base="xsd:string"/>
  </xsd:simpleType>

Shock of shocks, it's a no-restriction restriction from the base type of xsd:string. You can just see two spec writers hands getting tossed way up in the air on this one and being caught, if only tentatively, by wrists not anxious to end up with carpal tunnel syndrome from the attempt to express the XPath BNF rules as an XML schema restriction. (Those with formal language training can groan a little louder than the rest).

The point is that schema just can't touch this. But, the rules of XPath are clearly and normatively defined in the XPath recommendation, and the XForms recommendation dutifully cites XPath in its list of normative references. That's why the recommendation text is normative and the schema isn't.

Not to put too fine a point on this, but you might claim that the XPath example is a perverse one. Well, it's not the only one. For example, a number of XForms elements like input and select1 have a required single node binding. For the two elements I just mentioned, the single node binding attaches the user interface control to a node of instance data so that user input can be placed into the data model of the form. A single node binding can be expressed using either a ref attribute or a bind attribute. Unfortunately, XML schema doesn't have a way to express the requirement that one of two attributes must appear. So, in the schema for XForms, we say that both ref and bind are optional even though that's not very accurate. Separately, each is optional, but that's only the half of the story that XML schema can tell. The full story appears in the normative text of the XForms Recommendation.

Content-sniffing is a Valid Technique

Throughout the history of mathematics, new ideas have tended to be labeled in a demeaning way. The first few that come to mind are negative numbers, irrational numbers, and imaginary numbers. It's always as if the person who invents a new concept to solve a problem is somehow losing his mind because all the sane people use numbers that are positive, rational and real!

The same thing seems to be happening in the web world. I've recently heard the assertion that it is illegal to use XML constructs to upgrade the HTML language because it is illegal to send content over the wire as anything but tag soup if the content-type is text/html. On the one hand, I could be losing my mind, but on the other, maybe the assertion doesn't hold up to scrutiny. The argument seems to be that the user agent would have to commit the sin of content-sniffing in order to determine whether or not the text/html content can be fed to an XML parser. See how the label 'content-sniffing' just oozes negative connotations?!

Well, all of those clever mathematicians of old won out in the end because, quite frankly, their ideas worked. And so it will be with content-sniffing.

To be honest, I don't see the logical difference between testing a document for XML well-formedness versus checking a version attribute value to determine which aspects of a processor for the document will be active and which will be inactive. Before you rush to the comment link to tell me that the version attribute didn't work in HTML and was therefore removed, let me answer that it didn't work only because competing browser makers ignored it; they let features work that should not have worked by version. Had they implemented version checking, we would have had one less mess to clean up in today's web content. But that's water under the bridge now, and also beside the technical point that it can work.

In fact, all features that are placed into IBM Workplace Forms are activated by version. So, if you write a form using, say, version 6.0 of the XFDL language, the form continues to work in the same way in the latest version of the product. Changes to the way features work, and even most bug fixes, are implemented in a version-specific manner so that forms generally don't change behavior as the user agent is updated.

In essence, the Workplace Forms viewer products do a form of content-sniffing by activating certain subprocessors based on some of the content in the document. The point is that the document is still of content type application/vnd.xfdl, but we don't assume that a document processor must be dumb except for the information it derives from HTTP content negotiation. Perhaps this comes from our more document-centric focus-- after all, you don't get HTTP content negotiation when loading a form previously saved to the local disk drive!

The same kind of thing needs to happen with HTML processors. The html tag could bear a boolean attribute that indicates whether or not the content is well-formed XML. Or, there could be added a version tag whose value would imply whether XML was used. This way, new features of HTML could be added to the XML-based variant, and user agents could be required in the RFC 2119 sense to only provide access to the higher-level features by version. The result is that we could begin using new features as the carrot to encourage more XML-compliant content on the web without having user agents lose the ability to process existing content.

But either way, serving out well-formed XHTML with the content type of text/html is not only a valid thing to do, the simple truth of the matter is that people do it all the time. Why? Because it works.

XForms, Web Forms 2.0 and the future of XML content on the web

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!

Further to the Dr. Dobb's Developer Diary

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.

The chameleon namespace for XForms 1.1

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.

Announcement: Understanding XForms from Kurt Cagle

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:

1. Why XForms Matter, Revisited
2. The Model
3. Components
4. Customization
5. Events and Actions
6. 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.

Snakes on a Plane, aka repeats repeat things

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

1. Workplace Forms includes XForms
2. XForms contains a repeat element
3. 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.
4. 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.

Swimming with the Sharks

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.

News on XForms Progress

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.

Continuation: Aggregate Controls, Autotabbing and XForms

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)"/>

The advantage of XForms calculation is immediately clear when you consider that any user data entry automatically updates the combined phone number, so you don't have to write javascript in every control to cause the combined phone number to be recalculated.

Aggregate Controls, Auto-tabbing and XForms

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>

The 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!

Workplace Forms Trial Versions Now Available

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.

XForms submissions: asynchronous and synchronous

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.