You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2003/06/04 10:57:28 UTC

Workflow history file

Hi Lenya developers,

what do you think of the following draft of a workflow
history file:

<wf:history
     xmlns:wf="http://apache.org/cocoon/lenya/workflow/1.0"
     doctype="simple-document">

   <wf:version date="(?)" state="redaktion" user="michael"/>
   <wf:version date="(?)" event="publish" state="review" user="gregor"/>

</wf:history>

Each entry (besides the first one) marks a transition.
Attributes:
    - the event that triggered the transition
    - the user that invoked the event
    - the destination state of the transition
      (this is redundant, but it is quite hard to
      reproduce it, so I would add it to the history)

The question is how to insert the date so that it is
easily transformable into a human-readable format with XSLT.
Is there a typical or best-practise date element/attribute definition?

We could also add links to the task log files.
This would be unnecessary if
   - no task sequences are allowed (-> only one log file)
   - the task log date (=log filename) is the same as the transition date

What we would need next is a step in the document creation process
that creates a history file.

- Where do we want to put the history files?
- Should there be any connection to the revision files?

Andreas




---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org


Re: Workflow history file

Posted by Andreas Hartmann <an...@apache.org>.
Daniel Fagerstrom wrote:
> If the WF definition is going to be exported, then the sitemap is the 
> natural mechanism for exporting an URL to resource mapping from Cocoon 
> to the rest of the world. For internal references to a WF definition 
> within a Lenya server, a relative URL could then be used that implicitly 
> uses the cocoon: protocol.

It should be possible to use the workflow engine without Cocoon, e.g.
to invoke scheduled tasks when the servlet engine is down or from the
command line. So it might be a problem to serve the definitions
by Cocoon.

Of course we could think about decoupling the WF engine completely from
the CMS (in a separate Cocoon instance ...), but this is really overkill
at the moment. Nevertheless I will keep the WF engine as separated from
the CMS as possible on the implementation side.

> If the WF definition not is going to be exported, the use of the sitemap 
> would be overkill. Then the entity resolver could be used. Here we have 
> some other questions: where are the WF definitions going to be stored, 
> in one large file or in several files?

In several files.

> If the WF engine is going to be component based, the base URI (or the 
> whole URI) for WF definitions could be defined in the component 
> configuration file. The last part of the URI could be defined in the WF 
> definition file.

This sounds good. The mail archive will preserve these thoughts until
we are going to build the "great standalone workflow engine" :)

Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org


Re: Workflow history file

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Andreas Hartmann wrote:

> Daniel Fagerstrom wrote: 

...

>
>> I would propose to use an URI to identify a WF definition, it is the 
>> standard way of refering to resources at the web and for some 
>> applications it probably makes sense to publish the WF definition as 
>> well and in that case an URI is a natural way to find it.
>
>
> Yes, that sounds very reasonable. Then we need a way to map such URIs
> to workflow definitions. Is the entity catalog appropriate for this?

Might be, I don't know much about the entity catalog.

I think an important question is if WF definitions only are used 
internally withi Lenya or if it would be appropriate to export WF 
definitions to other Lenya based servers. I.e. for using a number of 
standardized WF definitions within an organization. I don't have enough 
knowlege about your usecases to have an opinion about that.

If the WF definition is going to be exported, then the sitemap is the 
natural mechanism for exporting an URL to resource mapping from Cocoon 
to the rest of the world. For internal references to a WF definition 
within a Lenya server, a relative URL could then be used that implicitly 
uses the cocoon: protocol.

If the WF definition not is going to be exported, the use of the sitemap 
would be overkill. Then the entity resolver could be used. Here we have 
some other questions: where are the WF definitions going to be stored, 
in one large file or in several files?

If the WF engine is going to be component based, the base URI (or the 
whole URI) for WF definitions could be defined in the component 
configuration file. The last part of the URI could be defined in the WF 
definition file.

>
>> If the WF history is separate from the WF instance, the WF history 
>> should refer to the instance identifier as well.
>
>
> That is done by the location of the history file - the path is equal
> to the document ID (= WF instance). 

ok

...

/Daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org


Re: Workflow history file

Posted by Andreas Hartmann <an...@apache.org>.
Daniel Fagerstrom wrote:

> Andreas Hartmann wrote:
> 
>> Hi Lenya developers,
>>
>> what do you think of the following draft of a workflow
>> history file:
>>
>> <wf:history
>>     xmlns:wf="http://apache.org/cocoon/lenya/workflow/1.0"
>>     doctype="simple-document">
>>
>>   <wf:version date="(?)" state="redaktion" user="michael"/>
>>   <wf:version date="(?)" event="publish" state="review" user="gregor"/>
>>
>> </wf:history> 
> 
> 
> I think that the WF history should refer to the WF definition as well. 

OK, that might be a good approach as it would increase the separation
of workflow from the CMS (no reference to doctypes in the workflow
history). Again some refactoring :)
But I have to make sure that no important information is lost.

> Otherwise it is unclear how the states, events and so on are defined.

This way, the mapping to states, events etc. is defined by the mapping
from document types to workflow schemas. But maybe we can leave out this
step (see above).

> I 
> would propose to use an URI to identify a WF definition, it is the 
> standard way of refering to resources at the web and for some 
> applications it probably makes sense to publish the WF definition as 
> well and in that case an URI is a natural way to find it.

Yes, that sounds very reasonable. Then we need a way to map such URIs
to workflow definitions. Is the entity catalog appropriate for this?

> If the WF history is separate from the WF instance, the WF history 
> should refer to the instance identifier as well.

That is done by the location of the history file - the path is equal
to the document ID (= WF instance).

> Is version a relevant name for all activities that are performed in th 
> WF? In the WFMC reference model they use the term activity instead, IIRC.

In the terminology I'm used to the term "activity" describes a process
that is executed during an automaton state. I'm not very pleased with
the term "version", but it was the first to come in my mind.

> XSLT 1.0 is rather weak at date handling, most XSLT processors (e.g. 
> Xalan) implements the date functions from exslt.org however. exslt 
> assumes the dates are represented as in XMLSchema part 2, i.e. as 
> YYYY-MM-DDThh:mm:ss, this is the format that will be used in XPath 2 as 
> well.

OK, we can use that, it seems to be quite standards compliant.

Andreas



---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org


Re: Workflow history file

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Andreas Hartmann wrote:

> Hi Lenya developers,
>
> what do you think of the following draft of a workflow
> history file:
>
> <wf:history
>     xmlns:wf="http://apache.org/cocoon/lenya/workflow/1.0"
>     doctype="simple-document">
>
>   <wf:version date="(?)" state="redaktion" user="michael"/>
>   <wf:version date="(?)" event="publish" state="review" user="gregor"/>
>
> </wf:history> 

I think that the WF history should refer to the WF definition as well. 
Otherwise it is unclear how the states, events and so on are defined. I 
would propose to use an URI to identify a WF definition, it is the 
standard way of refering to resources at the web and for some 
applications it probably makes sense to publish the WF definition as 
well and in that case an URI is a natural way to find it.

If the WF history is separate from the WF instance, the WF history 
should refer to the instance identifier as well.

Is version a relevant name for all activities that are performed in th 
WF? In the WFMC reference model they use the term activity instead, IIRC.

> Each entry (besides the first one) marks a transition.
> Attributes:
>    - the event that triggered the transition
>    - the user that invoked the event
>    - the destination state of the transition
>      (this is redundant, but it is quite hard to
>      reproduce it, so I would add it to the history)
>
> The question is how to insert the date so that it is
> easily transformable into a human-readable format with XSLT.
> Is there a typical or best-practise date element/attribute definition?

XSLT 1.0 is rather weak at date handling, most XSLT processors (e.g. 
Xalan) implements the date functions from exslt.org however. exslt 
assumes the dates are represented as in XMLSchema part 2, i.e. as 
YYYY-MM-DDThh:mm:ss, this is the format that will be used in XPath 2 as 
well.

> We could also add links to the task log files.
> This would be unnecessary if
>   - no task sequences are allowed (-> only one log file)
>   - the task log date (=log filename) is the same as the transition date
>
> What we would need next is a step in the document creation process
> that creates a history file.
>
> - Where do we want to put the history files?
> - Should there be any connection to the revision files?
>
> Andreas
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org


RE: Workflow history file

Posted by "Gregor J. Rothfuss" <gr...@wyona.com>.
>>
The question is how to insert the date so that it is
easily transformable into a human-readable format with XSLT.
Is there a typical or best-practise date element/attribute definition?
<<

that would be iso 8601, although there is controversy about
the canonical representation, and the ISO standards cost money
to look at them.. http://weblog.infoworld.com/udell/2002/09/29.html

-gregor


---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org