Data.driven()

Started to diagram the a high-level flow-chart of the Widget Processing Model for the Widgets 1.0 Spec using Visio. It is still early days, but hoping to submit it to the WAF Working Group soon for discussion. I’ve particularly focused on resolving the localization of content problem following the model used by Apple, Yahoo, and Microsoft. Opera does not support localization of their widgets through automated folder selection, which makes them the odd one out.

If you have comments, you can post them here or on the WAF public list (public-appformats@w3.org). I’m also hoping to republish the Widgets 1.0 Requirements document within the next few weeks.

April was a pretty crazy month. I held a WAF Working Group meeting at QUT, left the HTML Working Group, and then took a week off to walk the Overland Track in Tasmania (flickr photos!).

The working group meeting went well despite the fairly average attendance: we only had six members attend. I had hoped that at least 10 people would show up. On the upside, I finally got to meet Cameron McCormack and Lachlan Hunt (two new Australian recruits to the WAF Working Group) and we got lots of stuff done. The other people who attended included Art Barstow (Nokia, the Working Group chair), Guido Grassel (Nokia), and the always entertaining Anne van Kesteren (see picture, on the left). The minutes of the meeting are publically available at the w3c.

• April 17: Widgets requirements and spec.
• April 18: Access control, XBL 2.0
• April 19: All other business.

The meeting centered around our current work:

• Widgets
• Widgets reqs
• Access-control
• XBL 2.0
• XBL Primer
• XBL Test Suite

And Anne van Kesteren gave a presentation to QUT staff and students about the future of HTML… HTML5. (more…)

Recently got back from the Boston Face 2 Face meeting. While there I visited MIT, Nokia Research, and France Telecom (Orange) research labs. Check out the photos on flickr.

Responses to the Widgets 1.0 spec on the web have been mixed, but mostly positive with a few negative comments here and there. There have been some positive responses, like the one on Ajaxian. The brief article on Ajaxian seems to clearly capture the point of the spec:

Everyone and their mother have created their own widget specifications, and now as a developer you need to make choices. Do you want it to work on Dashboard? Google? MSN? Yahoo!?
If the big hitters supported this widget standard then we could write once, widget everywhere. Kinda

And another really good point they make is that…

This standard will live and die by the support that it gets.

Dare Obasanjo wrote a fairly negative blog entry about the Widgets spec seems to kinda miss the point (and Mark Baker points that out in the comments), because he seems to think that Widgets 1.0 is trying to address web page embedded widgets, which it is not.

Arve Bersvendsen, who edited the very first versions of the Widgets 1.0 spec, took time to briefly blog about the widget spec; and so did Anne van Kesteren (currently the other editor of the Widgets spec), stating in his blog entry about Widgets 1.0 that for some time I thought widgets were the latest marketing trick and pretty useless. Now I think they can actually be really useful (and fun) for creating simple applications using HTML, ECMAScript and CSS. The website Musings from Mars also thought that Widgets 1.0 was a good idea, saying let’s hope the world came settle on a standard that would let developers write widgets that would work on all the various platforms (Yahoo, Apple, Opera, Google, and, yes, Microsoft).

It seems that in general people get what Widgets 1.0 is all about. For those who don’t, lets be clear. The purpose of the spec is (IMHO):

1. stop fragmentation of the Widget development space, particularly in relation to metadata and the APIs.
2. to provide a standardized way to package, sign, code, and record metadata about widgets. The theory being that, if adopted by vendors, you could write a widget once and run it on any conforming widget engine (Yes! the same as Java applets). Of course, this second point is very complex (or screwed!) because of the API problem, which is the greatest challenge for the standardization of widgets. I return to this massive issue later.

I think the cause of confusion has partly been the name “Widgets 1.0″ and the lack of historical context around this spec. I guess this is why the original requirements document I wrote was named “packaging client-side web applications”. Even though the title made sure that very few people knew what the hell i was talking about, the title of my document captured (part) of the problem well… but capturing the problem well doesn’t help if people don’t know what the hell you are talking about. However, the Widget spec is wider in scope and so is the now renamed “Client-Side Web Applications (Widgets) Requirements” document. As I already discussed above, the scope of both documents now covers five issues surrounding widgets:

(more…)

This week I will start looking at how applications are packaged and distributed on both the client-side and server-side. Application packaging is basically the process of bundling an application into some kind of archive format (like a zip file) with instructions (usually in XML) for a host runtime about how to unpack that application and execute it. Application packaging is used on both the server-side, as is the case with J2EE WAR files and EAR files and .Net’s Cab files, and the client-side as is the case with Widgets such as those from Yahoo! and Opera. In this entry I will start comparing the different ways that companies package applications for deployment. The purpose of this excersise is to find the optimum way to package an application that is both lightweight enough for the client-side, and strong enough to cope with larger enterprise size applications on the server-side. This entry will serve as a foundation for a W3C Note on application packaging. It will be published as part of Web Application Formats Working Group. The Latest Draft of the document is available from the w3c dev website. (Please note that I am still working on this entry).
(more…)

I’ve been trying to convince QUT to let me on the let me joing the w3c’s Web Application Formats Working Group (WAF WG). The WG is basically looking at the problem that I am interested in: a declarative language for user interfaces and web applications. Their current focus, however, seems is on the XML binding language (XBL), which was originally proposed to the w3c by America Online, and then the SVG working group (sXBL). A second version of XBL, XBL 2.0, is currently being prepared and proposed by the mozilla foundation (and has now been given to the WAF-WG to work on). XBL is a way of binding elements to other resources (such as style sheets, some data/content, components, and scripts). For anyone who has done any web development, the applicaitons of this technology are pretty obvious. XBL has been partially implemented in Firefox (see SVG examples), but to what extent, I don’t know… something else to look into.

(more…)