Sunday, June 05, 2005

On Bleach, Entertainments, Forms, Atom, Kiss and Sexy MFs

Some ruminations on pragmatism, Bleached Unobtrusive Dom Scripting (BUDS), Forms, Atom, XForms, Glue, Infopath, "Entertainments", Kisses and the Sexy Mom Factor in Software...

On Bleach

So Adam Bosworth was reconsidering a programming style that some people would have us think must be called by a snappy acronym reminiscent of bleach or legendary Dutch Football clubs. Now I won't complain about said name because I realize the value of a coinage and have been evangelizing said style for quite some time. Still I haven't used that tag because I've been mindful of Fela's injunction against Yellow Fever, the practice in many African countries for people to bleach their skin to a lighter, more palatable, shade with gruesome chemicals (most banned in the West) and the consequent horrific effects on health (read what the bleach does to the resiliency of skin to minor cuts or otherwise routine surgery). The Nigerians and Congolese are prime exponents of this practice but even Ghanaian musical icons like Daddy Lumba have fallen into this Michael Jackson-turned-Diana Ross self-hating mindset which goes to show that the distortions of race are deeply rooted and occur in every society. Looking at the evolution of Daddy Lumba and the Congolese Koffi Olomide's faces over time is much like watching Jackson 5 videos and pondering the emaciated wreck the tabloids demonize today. Like Michael, Olomide has now taken to wearing face masks. As Fela sings
You deh bleach oh You deh bleach.
But maybe we all need to suffer for our art and perhaps the musical excitement has been consequently heightened.

On Entertainments

In any case Bosworth's notes are as-ever insightful and to the point and with his now official Googlejuice there is even more scrutiny in the subsequent blogospheric discussions. Equally enlightening is his response to the feedback his note provoked.

Technology Toli readers would know that this is a pet topic of mine and I've been writing a State of the DOM address every year ever since DOM scripting became Good Enough ® (circa 1997-1998) some of which are available on the wild web and have even found an audience (e.g. Applications vs. W3C DOM, On Rich Web applications, AlphaBlox and Oddpost and On Gmail and DHTML architecture again). I've been working on this year's version but keep getting distracted by the lure of technology folktales and B-movie scripts in the town of Deadwood.

A problem with my cacophonous take on blogging is that it's sometimes easier to go with "entertainments" than to write the technical monograph for Dr Dobbs and you run the risk of being characterized as mere fodder for the titillation quotient. In mitigation, I'm of the opinion that the conversational style helps you examine various aspects of an issue and get your ideas together en route to the book (and I suspect I've got a few books in me).

You can't seperate Graham Greene's entertainments and travel journalism from his serious and high-minded literature and indeed his later works wove all these strands into a cohesive whole. In my view Monsignor Quixote is more essential to the Greene canon than A Burnt Out Case or (and here I am not seeking to be controversial, I firmly believe this) The Power and The Glory. Also the occasional parable can elucidate essential truths very effectively, plus they're more fun. And since many people are visual, a good image, as our man Edward Tufte would admit can occasionally convey your point with greater force (read camels and eyes of needles or angels and pinheads etc).

On Forms and Rich Web Apps

The leitmotif in all of those DOM scripting pieces is that the browser can be construed as a programmatic surface that can be dynamically constructed and incrementally updated. The tradeoffs in that architectural style are all about client reach and efficiency, sometimes it is more expedient to deal with Plain Old Javascript Objects (to remix the POJO acronym) as the wire format and hidden iframes as the transport of choice. XML as the data format and XMLHTTPRequest as transport are nice-to-haves but not essential as various implementations have shown.

On the supposed failure of XForms or say Infopath, that one Bosworth's commentators notes, all I would say is that technology adoption takes time. The Big Bang of the web was rapid adoption of the web primitives (HTTP, URIs, HTML, XML, the HUHXtable sweater quartet), for content authoring and service deployment. We are now seeing a second Big Bang with the irrepressible blog phenomenon, Atom/RSS, and some might add wikis although to my mind the simplified wiki syntax leaks mightily in html authoring - those quote delimeter characters. Big Bangs are said by physicists to be rare events. Three Big Bangs in a decade is a little much.

Programmatic dynamic form-like applications, which after all are the design patterns that unobtrusive DOM scripting addresses were an afterthought in the development of web browsers. There were the empire-building distractions of more flashy, if leaky, mobile code (Java, ActiveX and Flash now recasted as Flex) which are also great but which raise not only issues of plugin installation, cross-platform support and hence ubiquity, but also accessibility, matters of focus and, more importantly, those user interface standards that the browsers codified: the back button for undo, the refresh button, the ability to bookmark etc.

Down the InfoPath

The problem space of forms in browsers is slightly different than the vanilla HTML authoring issue. The dominant OS vendor doesn't really want you to write applications first for the web but rather for its latest framework-du-jour thus the incentives are perverse in the Castle of Avalon. As a case in point, I explored Microsoft InfoPath a couple of years ago, based on public articles on MSDN and a couple of Jon Udell columns and had the following comments:
Let's start with Infopath's pervasive use of XSLT. XSLT is very difficult to hand author. I've written the hairiest of code before but XSLT strikes the fear of God into me.

Microsoft tied their form rendering engine to the Internet Explorer engine. Their runtime builds what is known as a Custom DOM to augment what in in IE. A web browser implements the standard DOM, an api that all web programmers write against. In InfoPath there are 2 new non-standard object hierarchies that are implemented.

They used non-standard extensions to HTML for their rendering, (behaviors and custom html attributes) and how they do validation (through what is called expando attributes).

We can infer what is supposed to happen, and when, by looking at their file format but the semantics are not easily understood nor indeed are they documented anywhere. Indeed they can and will change at a moment's notice...

The basic thing to understand is that while in InfoPath, Microsoft has followed the same separation of Model from Controls and Instance Data and Schema as XForms or say Adobe's XFT, almost all the technology choices they made make it very difficult to interoperate with them. I'm not sure that it was intentional, their programmers might just have been more familiar with those technologies, but the net effect is to tie their forms offering very tightly to their product line. They could have added their form processing extensions for a wider audience in Internet Explorer much as the Mozilla XFoms work is doing, but as a company they had no incentive, or desire, to add such functionality to a browser that they give away for free. With Infopath they could get you to pay to get this functionality...

It is costly to implement their notion of data binding (a combination of expando attributes on elements and html behaviors), their scripting runtime has its quirks (JScript, mshtml). Their custom dom is by far the most expensive to implement, and I don't believe that the XDocument.DOM and XDocument.Solution.DOM object hierarchies, nor their semantics and lifecycle are defined anywhere.

Reverse engineering the semantics of these objects that the InfoPath runtime adds to Internet Explorer is an expensive proposition. We don't have tools to author stylesheets and are hobbled too in their use of Internet Explorer Trident rendering engine. The type of html that is generated is full of the quirks that MSIE is known for.

It is costly to implement their controls since even the simplest controls are using behaviors. As an extreme example: text input boxes are not implemented using standard html input controls rather they are implemented as spans with custom behaviors and the contenteditable style.

Infopath has been 4+ years in the making, I'd hazard a 2 year effort at the very least not to mention dealing with all the various quirks in this still evolving runtime.

On Forms and Atom Glue

2 years later I'm glad that IBM's efforts weren't dissipated into chasing rainbows or these chimeric Redmond information paths, but still it is an ongoing struggle to convince people to ignore Microsoft. The good news is that the fun will begin not with Longhorn but rather when Mozilla includes either their XForms xpi or their parallel Web Forms 2.0 work in the default install of Firefox. It also helps that the subset of XForms 1.0 Mozilla has implemented is small enough that the Mozilla XForms runtime can fit in Minomo, the slimmed down version of Mozilla targeted for smaller devices. This is sure to get some operatic attention.

In this same vein, the indication that web rendering is where the action will be is that apparently some crazy glue layer wonks (who must not have slept for the past 2 years) can now transform Infopath forms into ASP.Net.

The other outlier will be if that apparently budding Bleached Unobtrusive DOM Scripting (BUDS) community manage to build and document frameworks that are easy to use and Good Enough ®. Again a shoutout to Alex Russell, think of lay programmers when building the Dojo toolkit, the latest recasting of the NetWindows dream. Jane Programmer is looking for a VB cookbook approach to this area.

T.V. Raman, Micah Dubinko and Steven Pemberton would argue that in XForms, they have Been trying to distill the essence of those heavy scripting applications and codify the design patterns therein. This emphasis on lowering the bar for authoring is alluding to something that goes under many names:And yes XPath has comprehension issues but those are leaks that can be plugged with enough work as Adam points out. Also the declarative versus procedural issue is an unresolved question and I see the value in both. As with all framework approaches to technology, what one is trying to achieve is to get things Good Enough © like Visual Basic or MFC on Windows so that leverage is inevitable.

Mark Birbeck is attempting to codify design patterns and to show that XForms as opposed to heavy and supposedly unobtrusive DOM scripting is the way forward. His latest patterns being Google Desktop Search and how to handle dynamic urls and Terraserver maps. This after Google Maps and Google Suggest. Slow down Mark, leave some work for others. People will think I'm a shill linking to you every week. And presumably if you continue to dance so attractively one of the big boys will swoop in and swallow your company up into some faceless Borg entity. That may be the point of course but I'm loving the creative exploration I'm seeing and working on the competition in the hope that the best of these breeds will distill this potent xforms confection.

On matters of glue and data, PubSub appears to be on the right track with their focus on Atom. Similarly when you see Matchmaker Fielding not merely lurking, but knocking heads on atom-syntax, or Adam's theorizing that Atom, as a mere wire format and publishing protocol, "could do for Information what HTML over HTTP did for user interface", you know that Atom is worthy of attention. My long lurking on that list is perhaps not time wasted.

Kiss and Sexy MFs

Finally to pick up on Adam's harkening to pragmatism at the end of his latest comment, I've recently been having some fun with neologisms, trying to name the kind of aesthetic I detect. I had completely forgotten about the Bosworth Axis of Empathy and now have to remedy that situation.

I had always figured Adam out for a KISS after reading Keep It Simple and Sloppy which reminded me not of those obvious rock stars who killed chickens on stage but rather of Prince who was also enamoured of the sloppy and sang
U Don't Have 2 Be Beautiful
2 Turn Me On ...

U Don't Have 2 Be Cool
2 Rule My World
Ain't No Particular Sign I'm More Compatible With
I Just Want Your Extra Time And Your


And with those Rock Star initials, I had painted him in a corner with fellow glue traveler Sam Ruby as a Radical Simplifier, Good Enougher or Technology Buzzword Demystifier (TBD). The other possible folksonomic tag was related to Godfather Bray as a Plain Old Loyal Oppositionist (Polo).

But loosely coupled with Adam's repeated emphasis on Simple, Sloppy, Standards that Scale in a web of data and the Mom Factor in technology, perhaps we should again turn to Prince who would say that were just in the business of Sexy MFs (Sexy Mom Factor Software).

But Adam, it turns out that you're a PITT (Pragmatic Inside-Out Technology Type). Glad to have you on the team, coach.

I had written about having both William Pitts as our mascots but it was pointed out to me that having Brad Pitt would be a better bet as a cheerleader not to mention that, in keeping with Kiss and Sexy MFs, he wears a mean skirt.


File under: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

No comments: