Smarter Everyone, Smarter Everything, Smarter Everywhere

Schema choices, XForms switch, and Data Validity

John M. Boyer 1,876 Views

The Workplace Forms Designer allows the form author to use an XML schema to automatically generate the instance data for an XForms model. The data nodes are needed to allow drag-and-drop associations to be created between the data and user interface components. You can drag from an existing UI control onto the data to make the association, or you can drag the data onto the form design canvas to cause the creation of a UI control that will then be bound to the data node. Either way, in XForms the association is made between instance data nodes and UI controls.

This is true even when the XML schema contains an element whose content is a choice. When this happens, the Workplace Forms Designer generates data according to the content of all possible choices. This allows form design to proceed for each of the possible choices. The expectation from XForms is that the form author will make all of the possible choices be non-relevant except the one actually chosen by the end-user. For example, if you have a choice of address block based on country selection, once you select "UK" then you get the UK address block, and once you select "US" then you get the US address block, and so forth. All address blocks other than the one for the selected country become non-relevant.

The use of non-relevance in XForms is significant. It affects two things, but the most important is that all non-relevant nodes are removed from XML data at the start of submission processing. This is important because an XML element with a schema choice content model is not valid until all but one of the choices is removed. This is called "pruning non-relevant nodes" in XForms, and it means that XForms does not expect instance data to be schema valid in situ, but rather it should be valid on submission.

[Read More]

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

John M. Boyer 2,487 Views

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!

[Read More]

Further to the Dr. Dobb's Developer Diary

John M. Boyer 2,105 Views

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.

[Read More]

Announcement: Understanding XForms from Kurt Cagle

John M. Boyer 1,971 Views

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:

These articles give a lot of information about the value proposition of XForms to projects, and they're worth your time.

[Read More]

Swimming with the Sharks

John M. Boyer 1,895 Views

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.

[Read More]

Feed for Blog Entries ▼ Feed for Blog Comments ▼

Blogs