[Osr-101] Implementing a very simplified workflow

[Josias Thöny]

Andreas Wuest wrote:
> Hi
> 
> On 3.4.2007 12:45 Uhr, Michael Wechner wrote:
> 
>> Hi
>>
>> It seems to me that most people are looking for a publish button 
>> within the Yulup menu, which corresponds to a very simple/crude 
>> workflow, e.g. one usecase could be:
>>
>> 1) User A edits a document through Yulup
>> 2) User A notifies User B abour the changes (e.g. through E-Mail)
>> 3) User B does review the changes of User A
>> 4.1) User B clicks on the publish button
>> 4.2) User B notifies User A that the changes need to be revised first 
>> (go back to 1)
>>
>> Even for this very simple "workflow" we still need to tell the users 
>> what is the live version and what is the latest version,
>> which means we first need to implement versioning resp. displaying 
>> revisions and the live status assigned to some specific version, e.g.
>>
>> Neutron Sidebar
>> ---------------+
>> Revisions      |
>> ---------------+
>> R 37           |
>> R 36           |
>> R 35 (live)    |
>> R 34           |
>> ....
>>
>>
>> WDYT?
> 
> What we need is a way to tell the server that he has to publish now, and 
> which revision (if the server supports versioning).
> 
> I've looked at the current workflow proposal 
> (http://neutron.wyona.org/amendments/workflow.html), which looks like this:
> 
> <introspection>
>   <resource
>     <edit mime-type="application/xhtml+xml" name="Homepage">
>       <open url="index.xhtml" method="GET"/>
>       <save url="index.xhtml?yanel.resource.usecase=save" method="POST"/>
>     </edit>
> 
>     <workflow>
>       <current-status date="2006.12.14">REVIEW</current-status>
>       <transitions>
>         <transition id="publish" from="REVIEW" to="LIVE"/>
>         <transition id="reject" from="REVIEW" to="AUTHORING"/>
>       </transitions>
>       <history>
>         <status date="2006.12.13">AUTHORING</status>
>       </history>
>     </workflow>
>   </resource
> </introspection>
> 
> Then, we have a versioning proposal 
> (http://neutron.wyona.org/amendments/versions.html) which looks like this:
> 
> <introspection>
>   <resource
>     <edit mime-type="application/xhtml+xml" name="Homepage">
>       <open url="index.xhtml" method="GET"/>
>       <save url="index.xhtml?yanel.resource.usecase=save" method="POST"/>
>     </edit>
> 
>     <versions>
>       <version url="index.xhtml?yanel.resource.revision=20843">
>          <comment>slugline updated</comment>
>          <date>2006-05-23T00:38:05+02:00</date>
>          <user>joe</user>
>          <revision>20843</revision>
>       </version>
>       <version url="index.xhtml?yanel.resource.revision=20023">title 
> changed</version>
>     </versions>
>   </resource
> </introspection>
> 
> Unfortunately, those two proposals seem to be doing similar stuff, but 
> in different ways, i.e. parts of the versioning proposal look like they 
> are duplicated in the workflow proposal.
> 
> My suggestion would be to add a <publish/> element as a child of 
> <version/>, e.g.
> 
> <versions>
>   <version url="index.xhtml?yanel.resource.revision=20843">
>     <comment>slugline updated</comment>
>     <date>2006-05-23T00:38:05+02:00</date>
>     <user>joe</user>
>     <revision>20843</revision>
>    *<publish 
> url="index.xhtml?yanel.resource.revision=20843&anel.resource.command=publish"/>* 
> 
>   </version>
>   <version url="index.xhtml?yanel.resource.revision=20023">title 
> changed</version>
> </versions>
> 
> If the server does not support versioning, it would still have to send a 
> <versions/> block, looking like e.g.
> 
> <versions>
>   <version url="index.xhtml">
>    *<publish url="index.xhtml?anel.resource.command=publish"/>*
>   </version>
> </versions>
> 
> Unfortunately, this does not blend in with the current workflow 
> proposal, which seems be built around transitions instead of versions 
> (which is IMHO a good thing), but then we can't determine how the server 
> should be informed about the chosen revision which should be published.

Couldn't we say that only the newest revision could be published?
It would simplify things and make workflow independent from versioning 
in the protocol.
Do you think this would significantly impair the flexibility?

Josias