Twice the summer of code

The Google Summer of Code^TM accepted students for 2010 were announced today.

This year, two interesting proposals related to State Chart XML were accepted. The first is about a web browser based runtime for SCXML and the second is about an Eclipse plugin for generating SCXML documents from state charts.

Congrats, Jake and Long! The two abstracts, respectively, are:

SCXML Code Generation Framework, JavaScript Edition (SCXML/cgf/js):
An SCXML-to-JavaScript Compiler Optimized for User Interface
Development on the World Wide Web

                   Abstract

This project has two goals. The first is to develop an SCXML-to-
JavaScript compiler optimized for User Interface development on the
World Wide Web. This would allow developers to elegantly describe
and implement Web-based UIs with complex behavioural requirements.
The second goal is to generate graphical depictions of statecharts,
which may then be animated in response to live UI events. This would
allow developers to better comprehend the dynamic behaviour
described by their statecharts.

and

An Eclipse-based Visual State Chart XML editor/debugger that
generates SCXML documents

                   Abstract

State Chart XML (SCXML) provides a generic state-machine based
execution environment based on Harel State Tables. It is very
useful to handler complex state transfer logic, but if a SCXML file
is large and complex, it will become too difficult to maintain and
refactor or to test its logic. This project aims to provide an
Eclipse and GMF based Visual Editor and Debugger for SCXML, which can
also be used to generate SCXML documents and code according to a
state chart.

Here's to a good summer to all involved!

Happy Diwali!

दीपावली की सबको शुभकामनाएं ।

दिवाळीच्या सग्ल्यांना खूप खूप शुभेच्छा

ਹੈਪੀ ਦੀਵਾਲੀ

દિવાલી મુબારક

শুভো দীপাবলী

தீபாவலிளி நல்வாழ்த்துகக்ள்

Ubiquity XForms 0.7.0 Released

Ubiquity XForms version 0.7.0 has been released.

The Ubiquity XForms processor allows developers to use XForms markup to create interactive web applications. Ubiquity XForms adds new APIs leveraging a number of popular AJAX libraries, making XForms processing available in standard web browsers, without the need for a download.

Since the last release (0.6.2), the team has worked to resolve some 220 issues and worked towards better XForms 1.1 conformance. Here are the implementation reports for Firefox 3 and Internet Explorer 7.

Here is a slightly abridged version of the 0.7.0 release notes:

       Ubiquity XForms 0.7.0 Release Notes

               Notable Changes

 * Roll-up: Ubiquity XForms roll-ups can now be built, packaging the entire library in one JavaScript file.
 * XForms 1.1 submission: Support for many more xf:submission features, including the xf:header element.
 * Validation: Ubiquity XForms now supports validation against the XForms predefined datatypes.
 * Function extension: JavaScript function extension mechanism to define JavaScript functions that can be called in form XPaths.
 * New map controls: Adding maps to your forms as easy as placing a CSS class value on an xf:output or xf:range.

               New features

 * Conditional action handlers are now available via @if; 
 * Messages can be displayed using xf:message; 
 * More XPath functions have been implemented, such as context(), event() and id(); 
 * The xf:repeat start index (@start) is now taken into account; 
 * The xf:toggle and xf:setindex action handlers have been added; 
 * The xf:method child of xf:submission is now supported; 
 * There is SOAP support on POST submissions; 
 * Support for some of the semantics of XForms in HTML has been added; 
 * @incremental is now working for xf:input, xf:secret, xf:textarea and xf:range; 
 * SHA-256 support has been added to the hmac() and digest() XPath functions; 
 * File writing is available, by using the file: scheme and the PUT method in submission; 
 * File reading is also available, by using the file: scheme and the GET method in submission; 
 * More control over how a user navigates a form is available via@navindex and @accesskey; 
 * xf:input's that bind to boolean data will now render as a check-box.

               Test system improvements

 * Hands-free execution of unit tests; 
 * W3C Test Suite now uses the Selenium Test Harness; 
 * There are more Selenium user extensions for XForms-specific testing; 
 * A Buildbot server has been setup for automated testing and results generation.

               Other changes

 * Improvements to form controls, such as xf:range, xf:select and xf:select1 controls; 
 * Improvements to xf:repeat; 
 * Improvements to action handlers, such as xf:insert, xf:delete and xf:load; 
 * Improvements to resource handling in submission, via xf:resource; 
 * Improvements to messaging, via xf:hint and xf:alert; 
 * Improvements to the processing model and the events generated; 
 * Improvements in MIP handling; 
 * Lazy-authoring improvements; 
 * Fixed dynamic relevance on xf:group; 
 * Various style improvements for form controls; 
 * SVN has been better organized, which means that the directory structure differs from release v0.6.2.

For more details, see the UsingTheLibrary and Release0.7 project wiki pages.

A number of samples are available, including ones that show integration with YUI widgets such as calendars and color pickers, the Google Maps API etc. Here is a screenshot of the map controls:



More detailed posts on individual features in this release coming soon.

Dotting the i in review

Any project with a code repository needs to be diligent with its revision history. Design decisions are made (and sometimes reversed), people move on, and the origin and rationale for artifacts in code needs preservation for posterity. Some tools and code review styles lend better than others for subsequent code forensics and traceability. While the RTC development style (Review-Then-Commit) offers reasonable benefits at ensuring immediate quality over CTR (Commit-Then-Review), it may cause loss of valuable information if iterations to a proposed change happen in a medium that doesn't preserve history.

Lets compare a few techniques.

CTR. Apache Commons.

In Apache Commons, committers change code at will. Luckily, we have a bunch of subscribers that look over the SVN diff emails that get sent out and some errors get caught due to community oversight and fixed in ensuing discussion. For bugs and fixes, the ASF JIRA is set up to annotate issues with relevant SVN commit messages containing the issue identifier.



Not all commits are related to JIRA issues, and we haven't gotten into the habit of insisting the same, so often there are what I call standalone commits -- islands of activity that cannot be tied into the issue tracker, discussions or other project tools.

RTC. Apache Tomcat.

In Apache Tomcat, some parts of the repository need enough developer confidence before a change can be committed to trunk. A low overhead version of RTC is used. A text file (see the Tomcat 5.5.x STATUS.txt file) is used for bookkeeping. A code change is proposed with a pointer to the diff and opinions are collected via votes to proposed changes. When a change goes into trunk, the proposal in the STATUS.txt file is removed.

In some cases, patches are in the ASF Bugzilla so there is a better record of them. In other cases, patches are posted in committer's personal web spaces. If there is ensuing discussion and a patch is updated, multiple times even, that bit of the code evolution is not recorded for the most part at worst and harder to retrieve at best.

RTC++. Ubiquity XForms.

In the Ubiquity XForms project, we use what I refer to as RTC++. The two pluses stand for:

+ Effective use of tracker - Each change must be attached to an issue in the tracker. Each issue in the tracker must bear the correct status at all times (Accepted, Started, InReview, Resolved etc.) and pointers to all related commits must appear in the issue comments.

+ Commit stream as a doubly linked list - Every proposed change from a working copy must first be committed to SVN in the changes/ space. During the code review stage, any iteration in the changes/ space based on feedback during the review process must serve as a node in a doubly linked list like so: the commit message should point to the previous iteration which is being improved on (if any) and the code review space should contain a comment about the next iteration (or commit to trunk). All commit messages must contain the issue identifier.

While it may seem like a bit more process, its actually a trivial overhead to RTC when you get it, and having just spent a couple of hours on code forensics I'm personally glad for every occassion where it was used correctly.

For an actual example in action, see Mark's blog post using issue 515 I recently proposed as an example.

Can you read that XML?

XML doesn't always provoke a good reaction on the readability front. Human readability, that is, rather than machine readability. Though often times, the examples of XML vocabularies that seem most tenuous are not designed with humans as the primary consumer in mind. Case in point: the UML2 XMI vocabulary subset for state machines as compared to SCXML. The former is undoubtedly convenient for machines, especially when you come at it from the tooling stack with editors in mind as it holds more graphical information that SCXML. With SCXML, on the other hand, human readability has always been an important design point.

I. To id or not to id

In SCXML, there is no need to id anything that is never again referred to. This includes <state>s, <invoke>s, <send>s etc. When a reference is needed, an id of the author's choice is supplied, with the caveat that the author has to ensure uniqueness. With XMI, for example, every state gets an generated id which is guaranteed to be unique and also guaranteed to be unreadable for humans. For example, its hard to say what the semantics of these states are with respect to the particular state machine at hand:

II. Lost and found

Graphically, each component of a state machine, be it a state or a transition or an entry point is a separate entity. XMI models the markup in a flat fashion, as a list of things on the screen all correlated using ids. SCXML nests certain elements in a manner that helps identify certain types of ownerships. For example, outbound transitions belong to the source state. Which means a state with three transitions looks like:

as against this (note that the snippet is really simplified, human readability ofcourse worsens exponentially with growing number of these elements):

III. Getting elemental

SCXML uses different element names for different types of pseudostates and state types (such as initial, history, state, final) which helps human readability whereas XMI uses the same element name.

Compare:

with:

VoiceXML 3.0 Third Working Draft published

The data layer, flow layer, profiles and event model building on DOM Level 3 events is shaping up. Kaz's announcement on www-voice:

Hi www-voice,

The third Working Draft of "Voice Extensible Markup Language
(VoiceXML) 3.0" has been published as follows.

This version:
  http://www.w3.org/TR/2009/WD-voicexml30-20090825/

Latest version:
  http://www.w3.org/TR/voicexml30/

Previous version:
  http://www.w3.org/TR/2009/WD-voicexml30-20090602/

A diff-marked version is also available for comparison purposes at:
http://www.w3.org/TR/2009/WD-voicexml30-20090825/diff.html

Best regards,

Kazuyuki Ashimura
for the W3C Voice Browser WG

Using UML2 Tools for SCXML

UML2 Tools from the Eclipse Model Development Tools (MDT) project provides a set of GMF-based (Graphical Modeling Framework) editors for viewing and editing UML models. After a quick install on Galileo, it was time for some experimentation. The diagramming feature-set is certainly more constrained than some of the other proprietary products in the space, particularly in the context of executable content in state machines. The model format used is XMI (XML Metadata Interchange) and there have been a couple of requests on Apache Commons user mailing list to get a stylesheet going to convert to State Chart XML (SCXML). r808257 adds the beginnings of such a stylesheet to the Commons SCXML extras.

A UML2 state machine diagram can actually contain multiple disconnected state machines. Since each needs to be styled to its own SCXML document, that clearly ruled in favor of using the less pervasive XSLT 2.0, for <xsl:result-document>. Which meant support for if-then-else in the XPaths came along, which turned out quite handy.

The transformation itself isn't too bad, once its bootstrapped. At the onset, to get the SCXML ball rolling, the first order of business is to determine whether the state machine has top level orthogonal states (<region>s in XMI). The second is to determine the initial state for each of the orthogonal states, which in XMI turns out to be a subvertex of type pseudostate with no value in the kind attribute i.e. subvertex[@xmi:type='uml:Pseudostate'][empty(@kind)]

And that gives us:

Once we get down from the region to the subvertex itself, the transformation is a straightforward switch on the type of the state to generate (abridged via ellipsis):

With increased UML2 Tools capabilities for the state machine diagram editor, many of us may soon have easy access to the model to middleware transformation below: