Menu

Forming Opinions, Part 3

May 4, 2005

Micah Dubinko

"Form has always come into being in a dialogue between particular instances and the larger body of work, or tradition" -- Richard Middleton

The previous two installments of XML-Deviant looked at Web Forms 2.0, or WF2, a Member Submission to the W3C. This week's installment concludes the review of that document.

Earlier, the review skipped over section 1, which contains a wealth of background information that helps position WF2 within the landscape of existing specifications and technology. The section begins with a set of guiding requirements, of which the most important ones can be paraphrased:

1. Backwards compatibility (where possible)
2. Re-use existing authors' knowledge
3. Be implementable on small devices

These requirements have exerted a commanding influence on WF2. For one example, instead of defining new elements in a new namespace, WF2 adds to and extends the XHTML namespace. Of course, when applied to SGML-flavored HTML, XML namespaces don't even enter into the picture; that the document attempts to modify both HTML and XHTML in similar ways shows how thoroughly the backwards compatibility argument threads through WF2. Similarly, work on web applications may soon be renamed "HTML5". It's pretty clear that the HTML working group is the proper venue for defining things in the XHTML and SGML 'namespace' (to use a looser version of the term). What gives?

As far as namespaces go, it is appealing to avoid them as much as possible when working with new markup. One of the most often quoted pieces of evidence about problems authors have with namespaces came from your humble author, in a position paper for the W3C workshop on compound documents. What I said has been paraphrased at times, so let's look at the full quote and context, which was underneath a section heading called "Tool-authored vs. Hand-authored Documents".

Namespace proliferation is a problem. Even fairly modest documents now require a huge raft of declarations at the top. As the author of an O'Reilly book on XForms, I can report that 90% of the technical questions from readers involve confusion related to namespaces.

As is appropriate for a W3C workshop aimed at uncovering bigger-than-a-single-Working-Group coordination problems and opportunities for improvement, the topic here is the larger W3C process. I was calling for change at more fundamental levels, not an excuse for an individual markup language design to do things in a way that will obviously conflict with the work of an existing Working Group.

In other words, the rules may stink, but you still have to play by them while working on getting them changed. Or do you?

¿Viva la revolución?

Does the W3C matter? Clearly it does to the players here, otherwise they wouldn't have bothered to make WF2 a Member Submission. The result, though brimming with good ideas, is an inherently conflicted specification.

In fiction writing, internal conflict is often a desirable quality for a character to exhibit. In technical specifications, though, it needs to be rooted out as thoroughly as possible. If you look at a cross-section of W3C technical reports that make it to the Recommendation stage, this is evident as a loosely common set of properties. Some are desirable, such as careful review of accessibility, international, and IPR issues, not to mention a certain level of respect from industry. Others are viewed by many as counter-productive, including namespace proliferation (or even use of namespaces at all), and reliance on other W3C technologies. These come as a complete package, though. Trying to pick and choose from both of these categories results in conflict.

Many in the XML community express concern that the browser vendors are once again starting down a path of dangerous "innovation" like the one that fragmented the web years ago. One example of this is the recent MozillaZine announcement for preliminary support for the canvas element, which provides a non-SVG means for client-side script to draw 2d graphics. The Talkback responses to that article contain a good sample of developer opinions on the subject. Apple's recent release of OS X 10.4 includes a version of Safari also with canvas support, though the Safari implementation may differ from both the Mozilla implementation and the developing specification document (the details are rapidly developing).

So as long as this isn't a full-scale revolution, it remains necessary to work with the W3C (where a Member Submission is a good first step) to avoid needless duplication of W3C efforts. Which leads to the final unreviewed section of WF2, the repetition model.

Re-repeated Repetition

Section 3 of WF2 starts off with an author's tutorial on the repetition model defined there. I have some idea of the kinds of issues involved in defining a repetition model, and I still had to re-read the intro several times to grasp how the thing works. Based on that experience, I've concluded that this section doesn't live up to one of the primary requirements of WF2: that it should provide familiar ground for existing developers.

Even more serious problems exist with WF2 repetition. In certain circumstances, the unusual syntax used in id attributes prevents validation from ever succeeding. Read that again: it's not a question of the lack of the right DTD to validate--it's that syntactic issues demote the entire document to well-formed status at best. Validation, one of the cornerstones of sensible web authoring, isn't compatible with this section of WF2.

Even if these problems could be solved, a perfectly good repetition model already exists in XForms. Since supporting older clients will unavoidably require shims such as client-side scripting, why not just reuse what's already here and working? The first requirement for the WF2 work--backwards compatibility where possible--could be turned around to indicate that the increasingly widespread use of XForms should be taken into account as part of the work.

Despite its foibles, the W3C serves as a moderating influence. At one time, somebody thought extending HTML with a blink element was a good idea; a bigger group, though, saw that the disadvantages outweighed the vendor enthusiasm. Things move slower at W3C because more eyeballs are involved--occasionally, this is even A Good Thing.

An upcoming issue of XML-Deviant will explore ways that "future work should be in collaboration with the W3C HTML and XForms Working Groups in order to promote the development of a single community", as stated in the W3C Team Comments.

Births, Deaths, and Marriages

Unofficial OASIS XML Catalogs Test Suite

Informal and not embraced by an standards body, but useful.

XML Pipeline Language (XPL) W3C Member Submission

Another XML pipeline proposal, based on Orbeon's experience gained through development of their product. Robin Cover has compiled an excellent list of related resources.

Simple XML-based Accounting System

XML Platform for XML trading capabilities for small Businesses.

Schematron seminar in Leuven Belgium

Thursday 19 May: "Expressing Business and Publishing Rules Using ISO Schematron"

Documents and Data

Late Breaking XTech presentations including Jo Walsh, Steven Pemberton, Mark Birbeck, and Ian Hickson.

Important factors in Software estimation.

Rick Jelliffe again on the difference between DTD and XSD.

Dimitre's Text Editor

And as long as we're talking about namespaces, read this.