Current state of WfXML-R definition?

[Diego Moreno]

Hi list!

I am thinking about adopting WfXML-R partialy in my OpenWFEru based project. But the most recent document I found is a Draft 5 version, dated on April 2008.

kswenson.com/wiki/attach/WfMC_20080422_Meeting/WfXML-R.pdf

This version is incomplete and I don't know if there is already a final version.

Regards.
Diego Moreno.

[Pat G Cappelaere]

Diego,

The next revision is still in the works.  I am waiting for some more inputs from Keith and various key people from the WFMC.

We have been selected to participate to the Open Geospatial Consortium Interoperability demonstration #6 with the Kickoff in October.

So a final revision will be coming soon.

If you have any comments or requests, now woudl be a good time.

Thanks,

Pat.

[Diego Moreno]

Hi Pat,
first of all, thank you for your answer. Maybe it is a good idea if I explain my project to you.

I am developing a workflow system with OpenWFEru, with the particularity that it has a Flex client (Flash-based client). Communication between the Flex client and OpenWFE is done using REST protocol. When I was thinking about using Atom for the data structure, I found your work with WfXML-R. I find your work very very interesting.

I know WfXML-R is thought for interface 4 (in Workflow Reference Model of WfMC). Our work is focused in interface 2, but I believe that we can also use WfXML-R there. Is it correct?

At the moment, the main functionality of Flex client is helping people fill formularies into the workflow-human interactions. Therefore, I need basically a way of representing current user workitems in Atom. And that section is empty in the Draft 5 version of WfXML-R specification. Do you have any "preview" of this part of specification?

On the other hand, one characteristic of my system is allowing dynamic view generation. I mean, each workitem has some special variables associated to it, which define the aspect of the formulary. My idea is using one of several templates, each one with a predefined layout, which include numbered multifunctional boxes, called fields. These special variables configure the content of those fields. Actually, we have a simple XML version of workitem representation:

<workitem>
  <id>2</id>
  <launcher>bob</launcher>
  <created_at> 2008-09-01T13:05:18Z </created_at>
  <updated_at> 2008-09-01T16:14:20Z </updated_at>
  <current_view>
    <field id="f01" type="label"> From Date: </field>
    <field id="f02" type="text_input" name="workitem[from_date]" />
    <field id="f03" type="label"> To Date: </field>
    <field id="f04" type="text_input" name="workitem[to_date]" />
    <field id="f05" type="label"> Reason: </field>
    <field id="f06" type="text_input" name="workitem[reason]" />
  </current_view>
</workitem>

Thanks to the easy Atom extension mechanism, I think we can handle these special variables (the ones in <current_view> tag) with an Atom extension that we define. For example, I could imagine one atom workitem representation:

<entry
    xmlns = "http://www.w3.org/2005/Atom"
    xmlns:g = "http://geobpms.geobliki.com/1.0"
    xmlns:v = "http://localhost:3000/scheme">

  <id>${hash}</id>
  <link href="http://localhost:3000/workitems/2.html" type="application/xhtml+xml" rel="self" />
  <link href="http://localhost:3000/workitems/2.atom" type="application/atom+xml" rel="self" />
  <link href="http://localhost:3000/workitems/2.atom" type="application/atom+xml" rel="edit"  />
  <author>
    <name> bob </name>
  </author>
  <title type="text"> Vacation Request </title>
  <created> 2008-09-01T13:05:18Z </created>
  <updated> 2008-09-01T16:14:20Z </updated>

  <g:item_type> workitems </g:item_type>

  <v:current_view>
    <v:field id="f01" type="label"> From Date: </v:field>
    <v:field id="f02" type="text_input" name="workitem[from_date]" />
    <v:field id="f03" type="label"> To Date: </v:field>
    <v:field id="f04" type="text_input" name="workitem[to_date]" />
    <v:field id="f05" type="label"> Reason: </v:field>
    <v:field id="f06" type="text_input" name="workitem[reason]" />
  </v:current_view>

</entry>

I still have to define it, but that is the idea. It should be an atom WfXML-R extension for dynamic view generation into workflow-human interaction. Do you think this is the correct way to do it?

Best regards,

Diego Moreno.

[Pat G Cappelaere]

On Sep 30, 2008, at 11:15 AM, Diego Moreno wrote:

Hi Pat,
first of all, thank you for your answer. Maybe it is a good idea if I explain my project to you.

I am developing a workflow system with OpenWFEru, with the particularity that it has a Flex client (Flash-based client). Communication between the Flex client and OpenWFE is done using REST protocol. When I was thinking about using Atom for the data structure, I found your work with WfXML-R. I find your work very very interesting.

This is actually what drove me to write the WfXML spec.  I had in mind a similar FLex-based GUI.  I started working on it and got derailed on some other stuff...

I think you are close.  A Workitem is a resource that needs to be exposed and accessed using AtomPub.  

A user ought to be able to GET it and update it (PUT).

I was going to add something to that effect in the spec.  I guess you beat me to it.

As soon as I get the next version from Keith, we will see where it fits best.

Thanks,

Pat.

[cappelaere]

Actually, Keith Swenson mentioned to me recently that someone at the
WfMC was going to work on a Work-Cast protocol.
Keith can certainly tell us more about it.
I would rather see this done as part of WfXML but referencing that
work would be ok too...
Pat.

[John Mettraux]

On Thu, Oct 23, 2008 at 10:32 AM, cappelaere <cappe...@gmail.com> wrote:
>
> Actually, Keith Swenson mentioned to me recently that someone at the
> WfMC was going to work on a Work-Cast protocol.

Hello Pat,

do you have a quick approximation of a definition of "Work-Cast" ?

Google and Wikipedia did not help.

Best regards,

--
John Mettraux - http://jmettraux.wordpress.com

[cappelaere]

Hey John,

I think that Keith really needs to chime in here. From what I
understand, the intent was to generate an atom feed when workitems
where queued to a user store. This would allow a user to get notified
within the browser (feed reader), get redirected to the store to
consume the workitem.

So the "work" is in defining the Atom feed format to contain the
relevant information for the user.

(And I really hope that Keith responds too}

V/R,
Pat.

On Oct 22, 9:37 pm, "John Mettraux" <jmettr...@gmail.com> wrote:

[Swenson, Keith]

Diego,

 

This is a subject I am spending time on just now.  You are correct, Wf-XML is normally associated with interface 4, but in the past it has overlapped a little with with interface 2 (you can access activities, but no search for workitems).

 

Kwanghoon Kim, a WfMC member from South Korea, has offered to lead an effort to make an open protocol for interface 2.  We are planning a meeting in Sunyvale California the week of Dec 8 to kick off this effort.  Anyone on this list interested in participating is welcome, but whether you come to the meeting or not I will make sure that the results are published here.

 

There are two aspects of this: one is what we call "WorkCast" protocol.  This is an extension of RSS which includes workitem information.  The great thing about this is that you can collect your worklists using a normal RSS reader.  The same extensions should be suitable for an atom feed.   We have a prototype running, and here is a sample of output:

 

<rss xmlns:ng="http://xxxxx" version="2.0">
    <channel>
        <title>My Active Tasks</title>
        <link>http://10.159.12.34:8080/nugen/MyTaskList.jsp</link>
        <description>List of active tasks</description>
        <item>
            <title>Oct 14-16, XYZ Customer Show</title>
            <link>http://10.159.12.34:8080/nugen/p/keithswenson/leaf.htm</link>
            <description/>
            <ng:state>4</ng:state>
            <ng:duedate>20081028T12:15Z</ng:duedate>
            <ng:expectedstartdate/>
            <ng:expectedenddate>20081028T12:15Z</ng:expectedenddate>
            <ng:duration>1</ng:duration>
            <ng:priority>0</ng:priority>
            <ng:assignee>http://kswenson.myopenid.com/</ng:assignee>
            <ng:progress/>
            <ng:process>http://10.159.12.34:8080/nugen/p/keithswenson/process.wfxml</ng:process>
            <ng:subprocess>http://10.159.12.34:8080/nugen/p/2008xyz/process.wfxml</ng:subprocess>
        </item>
        <item>
            <title>Sep 26, KM World Presentation</title>
            <link>http://10.159.12.34:8080/nugen/p/keithswenson/leaf.htm</link>
            <description/>
            <ng:state>3</ng:state>
            <ng:duedate>20080926T00:00:00Z</ng:duedate>
            <ng:expectedstartdate/>
            <ng:expectedenddate/>
            <ng:duration>1</ng:duration>
            <ng:priority>0</ng:priority>
            <ng:assignee>http://kswenson.myopenid.com/</ng:assignee>
            <ng:progress/>
            <ng:process>http://10.159.12.34:8080/nugen/p/keithswenson/process.wfxml</ng:process>
            <ng:subprocess>http://10.159.12.34:8080/nugen/p/kmworld2008presentation/process.wfxml</ng:subprocess>
        </item>
         ...

All of the "ng" tags are proposed.  The developer as defined a schema.  It appears (sorry) I don't have access to that schema at this moment, so I will send when I get the chance.  Many things are open: for example "state" should be a value that follows the WfMC activity state model.  This is just the worklist, the <link> tag hold a URL for a user interface that one would use to view the task and complete it.  We probably also need an <activity> tag that hols a REST oriented way to get the current activity state, and to update that activity state.  That would not be an RSS format, but a POX format, but probably re-using many of the same tags we have here.

 

In reading your message, I realize we have not attempted to put process values into this, but experience shows that users often want that.  We should discuss more.  My goal is just to get the ball rolling here a little bit.

 

-Keith Swenson

 

---

From: diego...@gmail.com [mailto:diego...@gmail.com] On Behalf Of Diego Moreno
Sent: Tuesday, September 30, 2008 8:16 AM
To: wf...@googlegroups.com
Cc: Swenson, Keith
Subject: Re: Current state of WfXML-R definition?

[Pat G Cappelaere]

Keith,

Thanks for sharing this effort.  Very nice work.

Cant wait to know more about it.

Pat.

[Diego Moreno]

Hi,
first of all, sorry for my delay in answering and thank you very much for all the information, Keith (I have already read your last document, WorkCastExtensionForRSS.doc).

I am very interested in Workcast/Wf-XML-R use on interface 2. My goal is to standardize the communications between a user client program and the workflow engine server. This communication is clearly done through interface 2 and we agree in that Workcast/Wf-XML-R is the right protocol for this.

Also, Wf-XML-R/Wokcast is perfect for web-based access through Internet to the workflow server.

On the other hand, user interaction with the workflow server will be done, normally, through formularies. Data filled by the user in these forms is information related to each workitem in a workflow. This way, information associated to a workitem could be in the RSS/Atom workitem representation. So I believe it would be very useful for some cases if WorkCast/Wf-XML-R supported this behavior.

Maybe some of these ideas could be included in the standard draft. Our research group could work in this line and carry out a proposal, more formal than my last example. Now, we are studing different ways to have rich formularies associated with workitems in a workflow. We are working with an Atom-based system because it allows bidirectional communication (client to server and vice versa) with AtomPub protocol.

Keith, thanks for the invitation to California but it will not be possible for me to do that trip (busy days for everyone, aren't they?). Nevertheless, I am very interested to know the results of that meeting.

Best regards,
Diego Moreno.

2008/11/25 Pat G Cappelaere <cappe...@gmail.com>