Push Button Paradise

Announcing UGO. I don't know what it stands for, but it's a framework to make today's browsers do wonderful and standards-compliant things. For example, it includes an optional XPath module ported from libxml2 C code to ECMAscript. The initial focus is on getting module loading to work, but soon this will enable all kinds of DENG-goodness in the browser, without requiring Flash. Link: http://demaledetti.net/ugo/ -m

A new release of Mitch Kapor's Chandler project is available. This one is "experimentally usable". I've done a bit of documentation on this release, and encourage anyone suffering from information overload to check it out, just don't expect to use it day-to-day (yet). Link: http://downloads.osafoundation.org/chandler/releases/0.4/ -m

On freenode.net, #laszlo, you'll find an increasing number of developers gathering to discuss this nifty Flash open source development tool, including official reps from Laszlo-the-company. Check it out. -m

Browsers really are capable of more than most people expect. Take this site, for instance: http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm A decent 2d graphics library, that runs in modern browsers with NO plugins at all. -m

I wrote a few days about about a format for compiling XPath into ECMAscript, to enable all kinds of unexpectedly neat things on the client. Today, I ran into some information that GMail does something very similar. Link: http://johnvey.com/features/gmailapi/ I'm starting to think this idea might have legs. -m

I need a good speakerphone (full-duplex), with two lines. 5.8G Wireless is OK but not critical. Any suggestions? -m

It's election season again in America, and that means one thing--more examples of terrible form design. See, for instance, this one, being used in the critical swing state of Ohio: http://www.electoral-vote.com/images/ohio-butterfly.jpg If you punch the box #14 thinking you're voting for Bush, you're actually throwing your vote away, barring more hanging chad nonsense. -m

This is a fairly random idea (a dream I had, actually) for "ECMApath", a highly pre-processed variant of XPath, suitable for use in client-side form environments like browsers. While the XPath data model is based on trees, the ECMApath data model is based on graphs. If you drew out a diagram, it would look much like the one in the XForms specification at http://www.w3.org/TR/xforms/index-all.html#rpm-processing-recalc-example .

Maybe the name isn't perfect, as all the "paths" get factored out. Instead of nodes, you have a bunch of Model Item Properties, each of which several properties, such as value, valid, readonly, required, relevant, calculate, constraint, etc. MIPs are loosely interconnected, as properties can reference other MIPs. Like a spreadsheet, interrelated properties will either work themselves out in the right sequence, or else fall in to a (detectable) infinite loop.

ECMApaths consist of executable ECMAscript. In the simplest example, an XPath binding of "/a/b/c" refers to a particular node in XPath terms, but a particular MIP in ECMApath terms. Thus:

"/a/b/c" -> "mip['UID0'].val"

Instead of .val, one could access other properties, such as .valid (whether the MIP is currently valid) or whatever.

Operators get mapped to ECMAscript operators, and existing functions get mapped to methods on a object named 'f', creatively enough, with all the hyphen characters mapped out of the name in a way that will look familiar to CSS users. Thus:

"/a/b/c div /a/b/d" -> "mip['UID1'].val / mip['UID2'].val"

"string-length(foo)" -> "f.stringLength(mip['UID3'].val)"

Things that represent full node-sets get expanded out:

"sum(line_ext)" -> "f.sum(mip['UID4'].val, mip['UID5'].val, mip['UID6'].val)"

This would work find for an XForms implementation, since anything that adds/removes nodes triggers a 'rebuild' event, where such adjustments can be made. Live node-sets, however, would still need to be tracked separately, for things like repeating sections that add/remove rows.

In the end, if a bit of information is kept around on where the MIPs originally came from, full XML can be reconstructed, as can things like urlencoded GET-friendly serializations.

This would take a lot of work up-front, probably more than would be practical in a first-stage XSLT. But it would enable highly-complete XForms engines that run in stock browsers, with no plugins necessary. -m

I hereby designate this week as a think week. No paying jobs, just general exploration of several existing open source projects, and clearing the mind and preparing for what's next. First step: unsubscribing from www-tag.

The discussions on www-tag (and of the TAG in general I take it) are just too incredibly brain-suckingly inate to stand any more. The one TAG meeting I participated in supported this opinion. I've said what I have to say there, e.g. http://lists.w3.org/Archives/Public/www-tag/2003Jul/0261.html Awhile back I helped nominate a well-respected person in the field for the TAG. The potential nominee refused, saying something that could probably be paraphrased as 'too incredibly brain-suckingly inate'. Not a good sign.

That's it, no more. Unsubscribed, deleted folder, emptied trash, compacted folders, good day. -m

Good things are happening in OpenOffice.org 2.0. Link: http://marketing.openoffice.org/ooocon2004/presentations/friday/vogelheim_XForms.pdf -m

Today was my last day at Verity, ending a great run of over six years. What's next? I need to do my own thing for a while. -m

I've been researching forms technology in Cocoon. Here is a draft response to Sylvain Wallez who posted an excellent, meaty comparison between XMLForms, a now-deprecated, kind-of-implementation of an ancient draft of XForms, and CForms, formerly called Woody and the primary forms engine in Cocoon now. XMLForms had lots of shortcomings. He asks whether these are reflected in the final XForms specification. Here I flesh out an answer before I post to the mailing list or wiki.

Link: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076 .

A major comparison point is I18N formatting. XForms handles this by defining a contract between the data and the UI. The data is ruled by XML Schema; the UI isn't. So a decimal value that appears as "3.14" in the XML, as defined by the Schema datatype, could be displayed to the user and entered as "3,14". Or "3.14". Individual form controls are responsible for implementing the conversion (if any) between storage value and display value.

The designers considered this a good 80/20 point. More detailed control is possible through extensions. To my knowledge, though, nobody has done this in a major way.

Another comparison point is regular formatting, like making sure your dollar amounts come out with the right number of decimal places. The idea is that a suitably defined datatype, like decimal with a fractionDigits facet of 2, would control formatting. (Or a date datatype would trigger a full calendar control, removing the need to have things like separate day/month/year entry boxes.) I had some trouble with this while writing XForms Essentials--in the example screen shots, whole dollar amounts kept coming out as "3.0" for example, datatypes or no. This would be a great area for community-standardization, along the lines of how exslt works across several XSLT engines.

Quoting the next observation: "XMLForm also has what I consider a strong security weakness : the default request parameter filter rejects only special parameters such as "cocoon-action-*", which means that a request can be hacked that modifies a part of the data model that wasn't available as a form field."

As I understand it, this behavior is Cocoon-specific. In straight XForms, you load starting data through XML, and only a single data instance gets modified. Any additional data instances you have around, say for business data or temporary use, are part of the XForms Model and can't be modified by incoming data.

"W3C XForms, which inspired XMLForm, is a client-side specification" ... not worth making a big deal out of, but probably useful for framing the discussion: XForms is defined in terms of things like events, and not tied to client-only implementations

Conclusion: I have immense respect for the work that Sylvain and others have done here. I don't think there will ever be 'one true forms' solution for Cocoon, simply because forms are so widely used everywhere. CForms is great, but there will always be people already using other stuff and integrating Cocoon into their world.

XForms is one of the things people want to use. Not that XForms solves all the world's problems out of the box, mind you. The combination of XForms and Cocoon would strengthen both sides, and provide feedback that can make both technologies better. -m

A new project announced--looks like something I've been kicking around. Link: http://xforms.zeninteractif.com/xhtml/index.html -m

In the North County area of Southern California, there's a great little coffee shop in Vista at Hacienda and Melrose. They have free wireless and amazing Brazillian fruit smoothies. After I had already camped out there a few days, I found out it had recently come under new management--by former co-worker Paul Reyes. I just wish there was a place like this in Phoenix. -m

In his book Green Mars (which I am currently reading), on page 446, one of the characters is researching a background on Frank Chalmers, who apparently died in the first book. It says of the National Service Corps: "The election of 2004 ended this period. The abrupt cancellation of the NSC was one of the new administration's first acts." We'll see. -m

One of the Laszlo-open-source articles going around quotes Ronald Schmelzer of ZapThink. I won't link to it, but I will debunk it. He calls Laszlo's decision to go open source "interesting" and "somewhat desperate"--three words with lots of spin and zero content. It gets worse...

He continues, "Startups now think that open source is the magic bullet." This is a cute opinion to have, just don't confuse it with a fact. Also, Laszlo is hardly a "startup"; it was founded four years ago, and they claim 11 million users.

Strawman thusly set up, he tries to knock it down. "There are two fallacies with this thought. First, that open source means free. If it's free, then open source by definition isn't a business model." Depending on how you read this, it's either meaningless or plain wrong. Lots of companies are doing fine with open source. Every day, more are realizing this--recently Orbeon made a similar announcement for a server-side product. Google for "open source business model", with the quotes, and your first hit will be a business model article I've referred to since the late 90's.

He concludes, "Second, why would a developer want to put their time and effort into developing a Flash-based application that has a limited market when you can spend the same amount of time developing on top of a platform that already has millions of users?" This is so fuzzy I'm not ever sure what he's trying to say here. The Laszlo technology runs on the millions of already-deployed Flash clients. Where's the problem? If anything, they have an advantage over Macromedia, who would likely try to roll out a new Flash engine with their latest technology, convincing folks all the way to upgrade. -m

David Temkin writes that now that Laszlo is open source, they are working on a server-less version; shades of DENG. An open source produce has a fundamentally different set of forces acting on it. Server licensing makes lots of sense as a technique for generating direct revenue--but when it's open it doesn't matter. Likewise with a proprietary file format. In short, watch this space for increasing convergence with open formats.

Link to David's weblog: http://www.davidtemkin.com/mtarchive/000007.html The Cocoon folks are talking about this, as are lots of others.

I think the key factor here is that Laszlo's LZX language, like XUL, has a great deal more detail than XForms. This is OK. Just like how blogging systems take a small amount of input and template it into a full presentation, XForms works to capture the basic intent behind a form, which can be combined with a template to produce a killer user interface.

I really need to play with this more. -m

I picked up a psc1200 (printer-scanner-copier) new/floor model. It was missing the little sticker that goes on the front panel to indicate what the buttons do. It turns out that without this sticker, the device completely refuses to function--not even enumerating on the USB bus. It further turns out this is an intentional design decision. Why, I have no idea.

A little snooping on the troubleshooting section of HP's site shows that the underside of the sticker has a bar code that gets scanned upon initial power-up. The system really wants to read this before it does anything else.

Is this some kind of evil DRM scheme? Copy prevention for the hardware? Does it phone home with this information? Does the firmware need to be told what model it needs to support? If you have info on this, please let me know.

I'm thinking DRM because 1) I'm paranoid that way, and 2) the (still-sealed) ink cartriges say "Not licensed for modification", whatever that means.

Anyway, I called tech support, and a new sticker is in the mail to me, and it only took one email and about 30 minues on the phone. Compared to my previous experience with HP support, this is amazing service. -m

In San Diego, I had the decadent experience of riding in a stretch Hummer limo. Lots of black leather, chrome, glass, and zebra-stripes. I had to ask: they get around 5 miles per gallon.

Verity really is a great place to work--they know how to treat employees. For me though, the next chapter continues. -m

Send me your XForms success stories, and I'll publish the top entries in a white paper I'm putting together. Have you put XForms into production anywhere? Have you seen it pop up in any unexpected places? If XForms has made your life easier, I want to hear about it. micah@dubinko.info -m

I'm on the road the next few days with limited connectivity. -m