Welcome To BlogerDesign

The previous three editions of XML-Deviant reviewed Web Forms 2.0, or WF2, a Member Submission made to the W3C by a loose group called The Web Hypertext Application Technology Working Group, often abbreviated WHATWG.

This week, continuing a web application theme leading up to the XTech Conference, XML-Deviant takes a look at the issues involving the broader internet application community. The first stop is the W3C Team Comment on WF2. Normally, the W3C won't acknowledge a Member Submission if it falls under the domain of an existing Working Group--in that case the submission should be made directly to the Working Group in question. As the lead-in quote shows, though, the submission was acknowledged. Additionally, the Team Comments offered a few specific suggestions:

1. Consider separating the backwards-compatible features from the features that require users to update their user agents or rely on scripting.

2. Provide comprehensive use cases and requirements for each enhancement.

3. Demonstrate how Web Forms 2.0 maps to XForms (and the reverse), giving more attention to the features in Web Forms 2.0 that are similar to XForms.

4. Participate in the development of XHTML and XForms specifications (note that Opera has been a member of the HTML Working Group for 4 years.)

5. Build a community, with cooperation from the W3C, to discuss, develop and promote adoption of improved forms on the Web.

While a good starting point, these comments by nature are addressed only to the WHATWG. That group didn't form in a vacuum; it formed as a response to pre-existing conditions in the community. Accordingly, any one-sided plan for change is simply doomed. On the other hand, the group is specifically asking for comments, so nobody should be surprised if some of the comments point to WF2. Even then, however, it's worth thinking about the wider implications of suggested changes. So with that, the remainder of this column offers some specific points for discussion and alignment within the community.

Point: Where the state goes. Earlier, this column's review of WF2 introduced FormAttic, a simple framework for client-side forms validation, in order to highlight an important discussion about the design of forms languages: namely, that new features require new information to be specified somewhere in a target document. FormAttic placed all the additional information in one place, in the document head. WF2 places the information across many elements throughout the document. Lots of ink could be spilled over discussions about which way is better.

But the interesting thing is that the existing XForms specification already caters to both ways. A fully specified XForms Model appears in one place in the document head, but for cases when that is too heavyweight, a technique called (with tongue firmly in cheek) lazy author style allows the scattered form control elements themselves to contain all the needed information. XForms and WF2 are more closely related than has been credited. Without serious changes to either specification, they could be even more so.

Point: Common foundation. The XForms Model, which is in turn based on the XPath data model and the XML Infoset, provides a common dictionary of terms for specifications and implementers to use. Note that this doesn't automatically imply the need to use XPath itself, only the data model, which in practical terms only means writing specifications a certain way and using certain terminology. The result will be that developers familiar with WF2 will have an immediate familiarity with XForms, and vice versa. Additional areas of overlap, especially around serialization and submission handling, can also be more easily identified this way. Many of the improvements found in areas of WF2 fit in with current work on the XForms 1.1 Working Draft.

Point: Common framework. WF2 is defined in terms of Modularization of XHTML, a framework for mixing and matching different parts of XML vocabularies. Without using a separate heavyweight specification, XForms uses another layer on top of XHTML Modularization to mix and match form-specific components. The result is diagrams like this puzzle piece, which as far back as 2001 already showed XHTML as an option for user interface. It should be possible to use the updated UI controls defined in WF2 with the rest of the XForms core, not to mention other kinds of combinations.

Point: Discard the WF2 repeat model in favor of the existing one. Previously I wrote about the WF2 repeat model, which has some shortcomings besides being duplicative. The WF2 submission itself acknowledges: "There is some debate about whether the repetition model section should be included or not."

Point: Acknowledge the need for a transition. This might be the hardest point for both respective sides to come to terms with, yet in some respects it's the easiest since it involves only editing one's viewpoint as opposed to editing a specification or working code. Perhaps Gerald Weinberg's Second Law of Consulting sums it up best: "No matter how it looks at first, it's always a people problem."

The huge quantity of existing code, markup, practice, and W3C Recommendations speaks for itself. So does the demand for more advanced solutions. There are valid 'before' and 'after' states in this discussion, which points to the need for a bridge between the two.

Another area of common ground comes from scripting, which any kind of client-side transition plan will involve. Work like FormFaces or DENG feel eerily similar to the kind of preliminary work going into WF2, such as that from the remarkable Dean Edwards. It doesn't take a big imaginative leap to visualize these kinds of projects coming together.

Point: Unify the community. One community working out these issues will be better than two or n, even though compromises will need to happen. The W3C might often get criticized for producing cumbersome "design-by-committee" specifications, but it still holds a leadership role in web applications standards space. If that weren't the case, the WHATWG wouldn't have made a Member Submission out of WF2 in the first place. The proprietary forms market is fractious enough. Let's not have the standards-based forms sector be the same way.

Conclusion

In preparing this article, I was stuck by how many areas of common ground exist between XForms and WF2, much more so than reading either specification alone would indicate. Still, not enough work has gone into identifying and expanding these areas. This is where XML-Deviant readers can help. In the comments section below or in your weblog, post some constructive comments, markup samples, or other ideas on how to move this community forward. A later issue of XML-Deviant will report on the progress.

Births, Deaths, and Marriages

OpenReader announcement: Open-standards eBook Format and Reading System

New discussion groups for Open-standards eBook Format development as well as a reference implementation.

Documents and Data

Uche Ogbuji's latest article, Principles of XML Design: When the Order of XML Elements Matters, which spawned a useful thread on xml-dev this week.

How to implement Google Maps (and other Ajax patterns) with XForms.

For more information on Gerald Weinberg's Laws of Consulting, see The Secrets of Consulting.