Forming Opinions, Part 3
May 4, 2005
"Form has always come into being in a dialogue between particular instances and the larger body of work, or tradition" -- Richard Middleton
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
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
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
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.
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
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,
of the cornerstones of sensible web authoring, isn't compatible with this section
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
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
Informal and not embraced by an standards body, but useful.
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.
XML Platform for XML trading capabilities for small Businesses.
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.
And as long as we're talking about namespaces, read this.