This page is for discussion of the model and XML syntax of SCUFL2 which will replace the current t2flow format.

Compare this with the t2flow XML schema - which has documentation about workflow elements as currently serialized.

The t2flow serialization format suffers from being very close to the Java object model, and contains various items that are simply Java beans serialized using XMLBeans. As the t2flow format is very verbose, it can be difficult to deal with for third party software to do inspection ("Which services does this workflow use?"), modification ("Change all calls to to") and generation ("Build a custom workflow from a button").

Developers have informed us that the old SCUFL format of Taverna 1 was significantly easier to work with. However, this format also has its caveats, like no schema, unidentified ways to extend service definitions for Taverna plugins and not supporting various new features in the Taverna 2 engine.

We have therefore decided to form a new serialisation format for workflows, called SCUFL2. This format will be accompanied with an UML model, and a primary serialisation format as XML, but also with possible secondary serialisations as JSON and RDF, all following the UML model. This model will also be reflected in a lightweight API, which can deserialize and serialize these formats, in addition to .scufl and .t2flow, but also more easily allow inspection of workflow structures, modification and generation.

As detailed in the Taverna roadmap, myGrid will be working on SCUFL2 during the summer 2010: (Subject to change)

June 2010 - SCUFL2 language specification draft
New Taverna workflow language specification more like SCUFL from Taverna 1.7.x to replace the current T2Flow serialisation format

July 2010 - SCUFL2 tools Beta
Including conversion from T2FLOW to SCUFL2, SCUFL2 to T2FLOW and SCUFL to SCUFL2
The supplied compiler will convert the above formats into internal Taverna workflow representation

September 2010 - SCUFL2 tools
A stabilised and fully tested version

See planned SCUFL2 tasks in myGrid's Jira.


This page reflect preliminary work, and these specifications are not yet at alpha level. Do not write any applications assuming the SCUFL2 format will stay as discussed on this page.

The code and definitions for SCUFL2 are kept in GitHub. Rough overview:

Material for iteration 2 of the UML Scufl model includes

Here is an attempt at demonstrating the new proposed XML syntax for Scufl2: as.scufl2.xml - a translation of as.t2flow

Suggestion for identifiers in Taverna URI templates.


From: Stian Soiland-Reyes <>
To: List for general discussion and hacking of the Taverna project <>
Date: Wed, 6 Jan 2010 10:47:34 +0000
Subject: Scufl 2 workflow language
Message-ID: <>


We're working on making the new SCUFL2 workflow language.

This will be a simplification of the current .t2flow serialisation, but will also come with an API.

We're basing this new workflow definition language on what we have learnt are the best features of Scufl (from Taverna 1) and .t2flow - Scufl was quite easy for third party suppliers to generate or parse (for instance myExperiment generates the Taverna 1 diagrams from scratch using Ruby code that parses the scufl), while .t2flow allowed to specify all the finer grained details possible in the new Taverna 2 engine - but this also made it a bit too verbose.

These are early days, so we'll figure out what the language should be and what the API should look like. Paolo Missier has done good work in making a proposed UML model of the new language, which we can then use as the basis for figuring out the XML serialisation, but also the Java beans of the API, and possibly also RDF and JSON versions.

In my spare time I've tried to tie together some simple Java beans implementing this UML model, and I've now checked this into Subversion. - these beans are not complete yet, have no integration with Taverna code, and the API can only serialise to RDF currently. (To test out Sesame/Elmo annotations on beans).

I might come back with code examples so we can discuss what the API should look like. The current tests only builds a workflow from scratch - also note that scufl2-rdf is not yet connected to scufl2-api and can be considered an early version of the scufl2-api. (API wise there are pulls in different directions, for instance we want to make it easy to inspect a workflow, but also to construct one. If more information is needed for inspection, this could make it more tricky to construct.)

The API should minimally be able to:

The API should be rich enough so that you could use it to generate the workflow diagram - ie. what the myExperiment does already in Ruby.


However, the API should also be lightweight, so it will not do tasks better done by Taverna engine (t2core):

Other tasks are also better suited for the main Taverna code base, as they require various plugins or other considerations:

If you talk about a client/server architecture, you can picture these (RESTful?) services:

(The last two of these should be possible to implement using mainly the Scufl2 API.)

A client could then use the Scufl2 API and a selection of these services - and still be able to implement what would look like the current Taverna workbench. The client could be written in a non-Java language, and use the Scufl2 serialisation schema/ontology directly with the help of whatever XML/RDF/JSON support is available for its language - this should give the same functionality but without a few convenience methods.

We're very interested in hearing about potential use cases for what such a SCUFL2 language and API could be used for. Feel free to add your comments!