Friday, May 31, 2002

I'm going offline for a week, but big news when I get back. Stay tuned. -m

Thursday, May 30, 2002

Great article on SMIL (the Synchronized Multimedia Integration Language) in this week's issue of xml.com. The writing style is nearly perfect--easy to understand and covering just the right areas. But the most interesting part was the history. Despite (or because of?) a great crowd of armchair enthusiasts condemning the W3C for putting out specs that are too complicated, SMIL 1.0 fell down because it simplified too much, and then hardly anyone deployed the technology. Things look more promising for SMIL 2.0, although I personally don't see "synchronized multimedia" in any form really taking off on the Web until the bandwidth monopolies loosen their grips. -m

Tuesday, May 21, 2002

BFMA Rehearsal: The Future of Web Forms

I'm presenting on Thursday at BFMA. Here's what I plan to say:

Part 1: The Big Picture

The History of Web Forms: Prehistory, HTML forms in 1993, stagnation until now: XForms. Demonstrated using the X-Smiles Browser.

HTML forms, in retrospect, are severely limited. Providing initial values requires painstaking document assembly; submitted data is in a choice of two formats (urlencoded or multipart/form-data), neither of which is any good at representing structured data; and script is required to do most useful things, such as validations, calculations, and dynamic user interface.

XForms by design nicely avoids these problems. It's based on "XML In; XML Out", which solves the problem of representing structured data (but still, it includes a mapping to flat urlencoded or multipart). This also means that XForms dovetails nicely with document-style Web Services and the raft of existing XML tools. It also leverages proven and well-known technologie of XPath, and also works well with XML Schema, XSLT, and SVG. Also, it is designed to work "any time, any place, and on any device"--universal access and accessibility.

Blurb: "XForms defines the 20% of functionality needed to replace 80% of all forms-related scripting."

Real-World Process Automation: Want to get the attention of a room full of overworked IT people? Say the word "reports". XML turns out to be a good tool to produce reports, with the benefit of XPath+XSLT. The other side of the equation is gathering data, with XPath+XForms. To complete the circle, reports can easily include forms to help gather data for the next round.

Part 2: What Are XForms?

Important terminology nits (from an editor): Always "XForms" never "XForm". The "XForms Processor" is the piece of software that interfaces between XML and a person. The "XForms Model" is the non-visible definition of a form, including calculations, validations, and a map of the "instance data" where user input gets stored. Since XForms is not a standalone document format, it always requires a "containing document" language, such as XHTML or SVG. The atomic things that collect user input (or output) are called "form controls". The connection between the XForms Model and the form controls is called "binding". It uses either XPath expressions or ID/IDREF to make the connection.

To meet the widely varying needs of users, XForms comes in two conformance profiles: "Full" (suitable for fat browsers and servers) and "Basic" (suitable for small devices, televisions, phones, PDA, and so on). Many adopters envision XForms in areas typically reserved for embedded solutions, such as gasoline pumps, cash registers, and copy machines.

A key concept in XForms is separating "purpose", embodied in the XForms Model, from "presentation", embodied in the form controls and other user interface markup. This means that a single form exists in two (or more) places in a containing document. For example, in XHTML, the "head" section would contain the markup for the XForms Model, and the "body" section would have numerous form controls. Once written, a single XForms Model can be though of as an interface that can plug into various user interfaces--obviously that defined in XForms--but also other languages such as Flash, PDF, and proprietary user interfaces.

Instance data is probably the biggest change, comparing XForms to HTML forms. Literally a chunk of XML, in any namespace, makes itself at home in the XForms Model. XPath expressions map various calculations, constraints, read-only restrictions, and required flags onto "nodes". Likewise, form controls are mapped to nodes, and exchange data in two directions. To support Web Services or other environments with dynamically generated XML, the instance data can be initially loaded from a URL, and can be associated with an XML Schema.

Another feature of XForms is that submit information is carefully spelled out. The result is more verbose than HTML forms, but also more powerful. The defaults are to submit the instance data serialized verbatim, as an HTTP POST. (REST note: HTTP GET is also supported, though not as XML for obvious reasons).

The design of form controls departs from that in HTML forms by describing the intent (rather than the presentation) of the control. "input", "secret", and "textarea" are straightforward. "select" and "select1" allow choosing many or one from a list (which might be rendered as radio buttons, checkboxes, a drop menu, a listbox, or any other possible renderings. Think too about possible non-visual renderings.) The "upload" control goes well beyond the file-picker heritage in HTML forms, specifying interfaces to microphones, cameras, scanners, digital ink, and nearly any other possible input device. A future specification will define CSS techniques to fine tune the presentation ('I want _that_ list to look like radio buttons'), but meanwhile, an attribute is provided to give a gentle hint to the processor.

More advanced user interaction is also possible. Grouping, nach. Also a "switch" mechanism that can show/hide entire blocks at a time, and can be used to create a multipage form in a single file. The most advanced function is that of "repeat", which creates dynamically expandable repeating lists, like you would expect on a purchase order.

If you've ever scripted HTML forms, you probably got real familiar with the "intrinsic events", such as <body onload="...">. The primary disadvantage of that system is that every event name needs to be coded into the language as a swarm of attributes. To solve this dilemma, the HTML Working Group has produced XML Events, which provides an more modular way to do this. XForms is the first specification to use XML Events. The response to an event, instead of always requiring script, can be specified in markup, called "XForms Actions". Possible actions include "message" (as modeless, modal, or tooltip), "submit", "setvalue", "setfocus", page switching, and simple browser navigation.

Part 3: What It All Means

Unified processing at last. Serious forms development today requires writing all the code twice: once on the client, and once on the server--since the client can never be trusted to not be a 14-year-old in a Telnet session. With XForms, the once-written XForms Model can be reused on both the client and the server, for a 50% reduction in effort off-the-bat. Also less CGI hackery would seem to help make the Web more secure.

A hot topic, at least for companies that like to sell things to the U.S. government, is Section 508 accessibility guidelines. Since XForms 1) is not keyboard or mouse-centric, 2) requires good practices like including labels and metadata, 3) has well defined focus and navigation events, and 4) reduces the amount of scripting needed--it's catching the fancy of a number of key players in the software field. Multimodal access, such as visual and audio at the same time, is another hot topic for XForms.

Companies that deal with paperwork elimination (including that mandated by the U.S. Paperwork Elimination Act) are also actively deploying XForms-based solutions, including workflow and routing. Think of the travel request form you filled out to come to this conference. It was a paper form, right? You filled it, signed it; then your manager signed it; then the accounting people got their hands on it; then it ended up in Human Resources. Now imagine the form data as XML, effortlessly floating across your network. Studies have shown a real-dollar savings of over USD $50 per transaction with this kind of technology.

Blurb: "How you gather, manage, and use information will determine whether you win or lose" -- Bill Gates

Latest Roadmap: Last Call on January 22. Coming up next: Candidate Recommendation and call for implementations, Proposed Recommendation, and Recommendation. ASAP.

Making the transition: You need to start getting ready today for XForms tomorrow. How?
* Deploy XML. Web Services (if necessary, and avoid RPC-style); XML, XML, XML. Get your data out there.
* Don't assume browser-only access. Expect phones, PDAs, and other exotic devices.
* Don't assume one-hop client-server processing. Think back to the travel request. Routing is the future.
* Embrace open standards.

Help make XForms better: Visit the Mozilla feature request and click on "vote for this bug". More votes means higher priority on implementation.

http://bugzilla.mozilla.org/show_bug.cgi?id=97806

For more information: subscribe to the mailing list: www-forms@w3.org (subject: 'subscribe').

-m

Monday, May 20, 2002

As a side note to the formalism discussion, I'll add that large doses of formalism can be quite useful during the design phase of a specification. The editor's job, however, is to translate this into a final document that's digestable by mortals. -m

Saturday, May 18, 2002

Excessive Formality Masks Bad Design

I'm increasingly disturbed by the trend for W3C specs to put strong emphasis on formalism.

Why is this disturbing? Isn't it a good thing to have a precise, rigorous specification? Precise--yes. Rigorous--yes. Formalistic--No. In its extreme form, formalism is a kind of showing-off, which only serves the purpose of demonstrating the vast intelligence of the specification framers. (Those who fall into this trap usually grasp the whole complex problem so well that they don't even realize that others are struggling.)

A much better approach, well-done in XPath 1.0, is to write a specification in english, with a minimum level of well-understood formalism, such as EBNF. Sure, this approach resulted in a few places in the spec that were initially underspecified (and later corrected with out too much hassle). More importantly, it made the specification accessible to everyday developers. As a result, XPath 1.0 is the biggest success story from the W3C since XML itself. Other Working Groups, like XForms, XML Signature, and DOM (not to mention the original XSLT and XPointer) have embraced XPath as a foundation.

This isn't about mushrooming page counts in specifications, although that is a symptom of a problem. It's about laying out the "big picture" in a shape that a large audience can fit it in their head; savor it; puzzle it through; apply the 'Cathedral and the Bazaar' network effect toward improving it. Excessive formality directly hinders this.

So, how does the XForms spec rate on the formality scale? You tell me. -m

Ideas for Standards Work

Dave Winer has some good thoughts on the standards process. -m

Saturday, May 11, 2002

Top Ten Paranoid Conspiracy Theories in XML

10 Processing instructions may cause drowsiness. Alcohol may intensify this effect
9 XML is too complicated on purpose
8 XML is too simple on purpose
7 Angle brackets are phallic symbols
6 'eXtensible Markup Language' considered correct spelling
5 XML is non-proprietary
4 Smart people are the best ones to write XML-related specifications
3 Elvis still alive; writing DTDs
2 XML Encryptions underwritten by the NSA

...and the number one paranoid conspiracy theory...

1 Top ten lists about XML can be funny

Wednesday, May 08, 2002

Next Wednesday, on May 15, I will be speaking at the GTC West conference. Topic: The role of XForms in government. Stop by and say 'hi'. -m

Tuesday, May 07, 2002

REST vs SOAP: The Final Word

Behave. Both of you. If you don't have anything constructive to say, then keep your mouths shut. I'm serious--don't make me pull this car over!

REST, as the older brother, you should know better. Quit telling SOAP he's worthless or that he should be exactly like you. Lots of people have told me how well he handles RPC. Can't you be more encouraging about his success?

And SOAP, wipe that smirk off your face. Just because REST is being obnoxious, that doesn't make him automatically wrong. I can't have you living under my roof and flaunting Web architecture. So clean up your act, or get out.

I love each of you just the way you are. But if you don't shape up, just wait until your father gets home! -m

Sunday, May 05, 2002

Bugzilla, the Mozilla database of feature requests (and the occasional bug), has a voting system, where participants can "vote" for a particular feature or bug fix. The Mozilla "drivers" use vote counts to guage the demand for the application of the limited engineering resources available. Implementing XForms reached the top 5 list this weekend. XForms support is listed as a target milestone of Mozilla 1.2 alpha, which is listed on the roadmap as beginning in July. -m

Thursday, May 02, 2002

The print edition of Information Week this week quoted a Slipstream exec as saying "Web services are as hot as Britney Spears". Was that a compliment or a slam?

Maybe just 'Oops, I POSTed again.' -m

I registered Zoot today. Zoot is an odd little program; the author describes it as a "Personal Information Processor". Basically, it stores text files, dates, addresses, phone numbers, and whatever in a lightning fast searchable database. It has a zillion keyboard shortcuts, which makes it even faster to use. The clincher, however, is the Zooter, an extra button and context menus it adds to the title bar of every application. Through the Zooter, you can rapidly move text into and out of any application. Zoot also has a friendly group of enthusiasts, on a mailing list that is helpful despite being hosted at Yahoo Groups. The little guys in software aren't dead, just restin'.

If you use Zoot, drop me a line, and we can swap zootly stories. -m

Wednesday, May 01, 2002

Blog life-cycle, phase 6: Vague promises about future blogs. Someday, I will write down my thoughts on SOAP and REST. Is Google a sinner or saint? -m

Blog life-cycle, phase 5: Complaining about not having anything to write about. -m

Blog life-cycle, phase 4: Shameless self-promotion. I notice that there's been little response to my message on the XForms mailing list about a trim profile of the new W3C forms language. The XForms Working Group has gone to great pains to involve the public in the process, so it would be a shame if nobody cares. The comment period closes 5 May. Send a 'subscribe' message to www-forms@w3.org and speak your mind. -m

Blog life-cycle, phase 3: The request for assistance. My notebook, a HP Pavilion XH535, has play, pause, rewind, and fast-forward buttons on the front. Anyone know of a Winamp plugin for this kind of hardware? -m

Blog life-cycle, phase 2: Linking to other weblogs. As a special bonus, this is a link to a blog entry that's about another blog entry. -m

Blog life-cycle, phase 1: In the beginning. I installed OpenOffice 1.0 today. Quite a few others did too, judging by the traffic on the main site and the mirrors. Good job guys! -m

Contact

mdubinko@yahoo.com

Terms of use

For external use only. I doubt the enforcability of click-through licenses anyway. Copyright 2003 Micah Dubinko. All rights reserved.