You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Markus Vaterlaus <mv...@mus.ch> on 2003/12/02 19:34:44 UTC
Re: [RT] Repositories and workflow states
Hello all,
just a few and late comments from my side....
> <snip/>
>
> Let's try to summarize the meaning of these "collections"
> (I'll call them repositories here):
>
> - They express a certain "processing state" of a document.
> This is related to, but not the same as the workflow state.
> I see a conceptual confusion here.
>
> "authoring/foo" is another document than "live/foo". It
> may be that both documents exist at the same time.
> When speaking in workflow terms, the "authoring"
> document has a workflow (it is in the "live" state),
> the "live" document doesn't.
>
> Up to here, it's a little confusing, but not a real problem.
> But what if we introduce a "staging" [1] repository?
I suggest that Lenya uses some predefines states (e.q. authoring,
staging, live, archive) . I would define these four as mandatory for
the application to work properly. If a set-up needs another additional
state (e.q. "Staging for the CEO", "trash") it should be possible for
the implementator to add it.
I'm not quite sure, if a document can exist in all states at the same
moment or if there are only some predefined combinations. However, I
think the idea to create a respository for each state is a good.
> Let's
> imagine the following scenario. The first term in the
> parenthesis is the repository (authoring, staging, live),
> the second is the workflow state (edited, ready).
>
> 1) create new document
> (authoring, edited)
>
> 2) submit
> (staging, ready)
>
> 3) publish
> (staging, published)
> (live, [none])
Maybe we need a definition of the terms. Here's my suggestion:
Workflow = Describes the lifecycle of a document
Workflow state = A defined state of a document within it's workflow
Workflow action = The transition from one workflow state to another
(aka steps) or a transition within the same
workflow state
For states use adjectives like authoring, staging et cetera
For actions use verbs open, edit, modify, delete, done et al.
Also, like with the states mentioned above, I suggest, that there are
some predefined and mandatory actions. Done - in my opinion - is such a
mandatory action. You should avoid a action like "none", because each
document has at any moment a well defined state, a known action who put
it there and several opportunities as next steps.
> Maybe someone has an idea how to improve this situation?
> I have the feeling that we should stronger decouple
> workflow states from repositories.
What's the gain from the decoupling?
> My first idea is to use a common workflow instance
> for all "incarnations" of a document in different
> repositories. A workflow instance wouldn't be assigned
> to a document, but rather to a document "group".
>
> We could also reconsider the term "document":
> A document would be the union of all incarnations.
>
Good point. What is a document? I would define it like that:
All information relevant for the publication of the document. This
means all contents like title, body, notes. All assets like links,
images, sounds et cereta. And all meta-information like keywords,
author, modification date et cetera. In certain cases also the
different language versions may belong to one document. However, I
don't have an idea at the moment how to solve the problem with
translations which leads to new states not needed in every language.
--mv
> Constructive ideas are very much appreciated ... :)
>
> ------------------------------------------------
>
> [1] Couldn't we make this approach more generic?
> (e.g., configuring the repositories for each
> publication instead of hard-coding them in the
> Publication class)
>
> ------------------------------------------------
>
> Thanks!
>
> -- 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: [RT] Repositories and workflow states
Posted by "B.K. DeLong" <bk...@pobox.com>.
At 04:59 PM 12/3/2003 -0500, you wrote:
>heh. serendipity strikes again. i actually had lunch with cecilia
>d'oliveira about this today.
>
>http://ocw.mit.edu/OcwWeb/Global/AboutOCW/organization.htm
Well, not quite. She mentioned lunch and asked if I had heard of Lenya ;) I
decided to jump right in rather than drive some other open source effort.
>i hope to make it to OCW early next year so that i can show you lenya and
>you guys can show me what you have got with your existing system.
>
>too bad you missed yesterday's lenya seminar..
Yes, definitely. I'm hoping we can build in things like bug tracking, a
blogging component, more advanced metadata options etc.
Here's to a good partnership ;)
--
B.K. DeLong
Web Production Specialist
MIT OpenCourseWare
9-225
+1.617.324.6044
+1.617.797.2472 (cell)
bkdelong@mit.edu
http://ocw.mit.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [RT] Repositories and workflow states
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
B.K. DeLong wrote:
> Hi -
>
> My name is B.K. DeLong and I joined the list in hopes that the OCW
> project can someday use Lenya to propagate OpenCourseWares to colleges
> and universities across the world. Ideally we can use Lenya and
> customize it for our needs and then make it available for download. But
> this is a total fantasy- I joined the list to see how I can help and
> maybe give suggestions that may benefit not only us, but other groups
> using the software.
heh. serendipity strikes again. i actually had lunch with cecilia
d'oliveira about this today.
http://ocw.mit.edu/OcwWeb/Global/AboutOCW/organization.htm
i hope to make it to OCW early next year so that i can show you lenya
and you guys can show me what you have got with your existing system.
too bad you missed yesterday's lenya seminar..
best,
-gregor
--
Gregor J. Rothfuss
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [RT] Repositories and workflow states
Posted by "B.K. DeLong" <bk...@pobox.com>.
Hi -
My name is B.K. DeLong and I joined the list in hopes that the OCW project
can someday use Lenya to propagate OpenCourseWares to colleges and
universities across the world. Ideally we can use Lenya and customize it
for our needs and then make it available for download. But this is a total
fantasy- I joined the list to see how I can help and maybe give suggestions
that may benefit not only us, but other groups using the software.
I haven't gone too far back into the archives, but the below discussion
looked familiar so I thought I'd just jump in. These are just contributory
comments - nothing authoritative ;)
At 08:51 PM 12/3/2003 +0100, you wrote:
>>>>Up to here, it's a little confusing, but not a real problem.
>>>>But what if we introduce a "staging" [1] repository?
>>>I suggest that Lenya uses some predefines states (e.q. authoring,
>>>staging, live, archive) .
>>
>>IMO this is too rigid. Why should this be useful?
>
>My idea came from the fact, that most implementations of CMS I'm aware of,
>or publishing processes I know of, use these four states. Depending on the
>workflows, there might be less (rare) or more. To support a short
>implementation period and providing fast results, it makes in my opinion
>pretty much sense to have some predefined states to build on
I think it would be incredibly useful - OCW's CMS doesn't have archiving in
the workflow yet, but we have Authoring, QA, Staging and Publishing. OCW
courses will eventually be archived into DSpace. We have a team of about 10
authors working on courses which go through a three-tier QA process with
the Course Owner, then the Production Manager and finally the Professor.
Then it goes to Staging so we can see what it looks like and allow the
professor to see the site before its made live. Publish is the absolute
last thing we do. If there was an error in QA, it gets kicked back to
Authoring. If the Professor doesn't like something, it gets kicked back to
Authoring and gets QA'd again before pushed back to Staging and reviewed by
the professor.
>>>I'm not quite sure, if a document can exist in all states at the same
>>>moment or if there are only some predefined combinations.
>>
>>ATM a document can only exist in one state at a time
>>(state machine concept). But I guess Michael will come up
>>with a proposal for multiple workflow instances per document
>>soon.
>
>Sounds like a good idea to me. Therefore, I'm looking forward for
>Michael's proposal.
We did have a parallel workflow at one point - it used to go Authoring -
Initial QA/Metadata Approval/Intellectual Property Approval - Final QA -
Staging - Publishing. The idea was that once authoring was done, the
library could populate all the Metadata in the course and our IP team could
track and approve/deny the intellectual property status for an object or
page while the Faculty Liaison or Publication person did a first QA run.
Once that stage is done, it got QA'd a final time by the Faculty Liaison to
make sure there weren't any changes during the Metadata or IP stage....or
in case the Professor got something in late.
Long story short, it didn't work for us but the ability to have parallel
workflows may be helpful.
>>>However, I think the idea to create a respository for each state is a good.
>>
>>Why? I don't see the purpose of a relation between
>>workflow state and repositories.
>
>If I got it right ATM we have this at Lenya. A document is in a defines
>state, let's say published, and is found in "live". Or did I get something
>wrong?
I'm not sure if a repository for each workflow state is necessary - at
Staging it gets ftp'd to the set Staging Server and when Published, to the
Publishing server. Provided one can see the site as it would look published
to Staging or Publishing in the CMS while Authoring or doing QA...then
there should be no need for extra repositories as long as the state is
defined somewhere.
>>>Workflow = Describes the lifecycle of a document
>>>Workflow state = A defined state of a document within it's workflow
>>>Workflow action = The transition from one workflow state to another
>>> (aka steps) or a transition within the same
>>> workflow state
>>
>>Action = Transition might be confusing, because the term
>>"action" has another meaning in automata theory (which the
>>Lenya workflow is based on).
>
>Has anybody a better idea?
heh - not sure. I just "push it through workflow".
>>>And all meta-information like keywords, author, modification date et cetera.
>>
>>>In certain cases also the different language versions may belong to one
>>>document.
>>
>>This issue has to be discussed.
>>>However, I don't have an idea at the moment how to solve the problem
>>>with translations which leads to new states not needed in every language.
FYI - I know one of the problems we ran into with our CMS and use of
templates for pages is we were unable to specify different charsets. For
instance a Japanese course using kanji needs the correct charset to say to
the user agent "display the kanji font".
>I meant, that if the different language versions are part of the document,
>then you might come up with different sub-workflows for each language.
>Imagine, if you are in Switzerland or Germany and have a web-site offering
>the same contents in german, french and english and a native author, then
>the german version needs no translation, but the other two do. Or, maybe
>you want to publish your contents as soon as they are ready for
>publishing. The german version will in this case be in a different
>workflow state (published) than the french or the english version, because
>they need some more time for translation. However, maybe one should better
>start three different documents in such a situation.
Yup - separate documents for multiple language versions would be great.
--
B.K. DeLong
Web Production Specialist
MIT OpenCourseWare
9-225
+1.617.324.6044
+1.617.797.2472 (cell)
bkdelong@mit.edu
http://ocw.mit.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [RT] Repositories and workflow states
Posted by Andreas Hartmann <an...@apache.org>.
Markus Vaterlaus wrote:
>>>> Up to here, it's a little confusing, but not a real problem.
>>>> But what if we introduce a "staging" [1] repository?
>>>
>>> I suggest that Lenya uses some predefines states (e.q. authoring,
>>> staging, live, archive) .
>>
>>
>> IMO this is too rigid. Why should this be useful?
>>
>
> My idea came from the fact, that most implementations of CMS I'm aware
> of, or publishing processes I know of, use these four states. Depending
> on the workflows, there might be less (rare) or more. To support a short
> implementation period and providing fast results, it makes in my opinion
> pretty much sense to have some predefined states to build on
The states are configured in the workflow schema specification file,
so the integrator could just use an existing workflow specification
(e.g., from one of the CVS publications) and customize it.
[...]
>>> However, I think the idea to create a respository for each state is a
>>> good.
>>
>>
>> Why? I don't see the purpose of a relation between
>> workflow state and repositories.
>
>
> If I got it right ATM we have this at Lenya. A document is in a defines
> state, let's say published, and is found in "live". Or did I get
> something wrong?
This is publication-specific. E.g., in the default publication, the
document is always located in the authoring directory. If the state
variable "is_live" has the value "true", a copy of the document exists
in the live directory.
>>> Workflow = Describes the lifecycle of a document
>>> Workflow state = A defined state of a document within it's workflow
>>> Workflow action = The transition from one workflow state to another
>>> (aka steps) or a transition within the same
>>> workflow state
>>
>>
>> Action = Transition might be confusing, because the term
>> "action" has another meaning in automata theory (which the
>> Lenya workflow is based on).
>
> Has anybody a better idea?
What's wrong with the term "transition" to describe a transition?
[...]
>>
>>> Also, like with the states mentioned above, I suggest, that there are
>>> some predefined and mandatory actions.
>>
>> Why?
>
> For example, a new document must always be opened first. Also if you
> want to delete or archive a document, this is the same for all instances.
I'd rather see any mandatory operations incorporated
in the publication layer. This allows flexible workflow
schemas and at the same time minimizes the danger
of inconsistent sites/documents.
[...]
>>> However, I don't have an idea at the moment how to solve the problem
>>> with translations which leads to new states not needed in every
>>> language.
>>
>>
>> What do you mean here?
>
> Just saw today, that there is another thread about the problem of
> different language versions and how to deal with that. Maybe the
> discussion there brought up a solution already.
>
> I meant, that if the different language versions are part of the
> document, then you might come up with different sub-workflows for each
> language.
> Imagine, if you are in Switzerland or Germany and have a
> web-site offering the same contents in german, french and english and a
> native author, then the german version needs no translation, but the
> other two do. Or, maybe you want to publish your contents as soon as
> they are ready for publishing. The german version will in this case be
> in a different workflow state (published) than the french or the english
> version, because they need some more time for translation.
Good point - this makes sense.
> However,
> maybe one should better start three different documents in such a
> situation.
This would be one solution - different doctypes for different
languages (possible with the current implementation).
The other solution would be to assign different workflow
schemas to different language versions. This would require
changing the API, but feel free to make a proposal :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [RT] Repositories and workflow states
Posted by Markus Vaterlaus <mv...@mus.ch>.
>>> Up to here, it's a little confusing, but not a real problem.
>>> But what if we introduce a "staging" [1] repository?
>> I suggest that Lenya uses some predefines states (e.q. authoring,
>> staging, live, archive) .
>
> IMO this is too rigid. Why should this be useful?
>
My idea came from the fact, that most implementations of CMS I'm aware
of, or publishing processes I know of, use these four states. Depending
on the workflows, there might be less (rare) or more. To support a
short implementation period and providing fast results, it makes in my
opinion pretty much sense to have some predefined states to build on
>> I'm not quite sure, if a document can exist in all states at the same
>> moment or if there are only some predefined combinations.
>
> ATM a document can only exist in one state at a time
> (state machine concept). But I guess Michael will come up
> with a proposal for multiple workflow instances per document
> soon.
Sounds like a good idea to me. Therefore, I'm looking forward for
Michael's proposal.
>> However, I think the idea to create a respository for each state is a
>> good.
>
> Why? I don't see the purpose of a relation between
> workflow state and repositories.
If I got it right ATM we have this at Lenya. A document is in a defines
state, let's say published, and is found in "live". Or did I get
something wrong?
>> Workflow = Describes the lifecycle of a document
>> Workflow state = A defined state of a document within it's workflow
>> Workflow action = The transition from one workflow state to another
>> (aka steps) or a transition within the same
>> workflow state
>
> Action = Transition might be confusing, because the term
> "action" has another meaning in automata theory (which the
> Lenya workflow is based on).
Has anybody a better idea?
>> For states use adjectives like authoring, staging et cetera
>> For actions use verbs open, edit, modify, delete, done et al.
>
> This could be a useful recommendation.
>
>> Also, like with the states mentioned above, I suggest, that there are
>> some predefined and mandatory actions.
>
> Why?
For example, a new document must always be opened first. Also if you
want to delete or archive a document, this is the same for all
instances.
>>> My first idea is to use a common workflow instance
>>> for all "incarnations" of a document in different
>>> repositories. A workflow instance wouldn't be assigned
>>> to a document, but rather to a document "group".
>>>
>>> We could also reconsider the term "document":
>>> A document would be the union of all incarnations.
>>>
>> Good point. What is a document? I would define it like that:
>> All information relevant for the publication of the document.
>
> This might be confusing. The information relevant for the
> "publication" (publishing?) of a document involves its
> location, site structure dependencies, etc. which I wouldn't
> assign to the document itself.
+1
>> This means all contents like title, body, notes. All assets like
>> links, images, sounds et cereta.
>
> Rather "references to ..."
+1
>> And all meta-information like keywords, author, modification date et
>> cetera.
>
>> In certain cases also the different language versions may belong to
>> one document.
>
> This issue has to be discussed.
>> However, I don't have an idea at the moment how to solve the problem
>> with translations which leads to new states not needed in every
>> language.
>
> What do you mean here?
Just saw today, that there is another thread about the problem of
different language versions and how to deal with that. Maybe the
discussion there brought up a solution already.
I meant, that if the different language versions are part of the
document, then you might come up with different sub-workflows for each
language. Imagine, if you are in Switzerland or Germany and have a
web-site offering the same contents in german, french and english and a
native author, then the german version needs no translation, but the
other two do. Or, maybe you want to publish your contents as soon as
they are ready for publishing. The german version will in this case be
in a different workflow state (published) than the french or the
english version, because they need some more time for translation.
However, maybe one should better start three different documents in
such a situation.
> Thanks for your comments!
>
You are welcome!
--mv
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [RT] Repositories and workflow states
Posted by Andreas Hartmann <an...@apache.org>.
Markus Vaterlaus wrote:
> Hello all,
>
> just a few and late comments from my side....
>
>> <snip/>
>>
>> Let's try to summarize the meaning of these "collections"
>> (I'll call them repositories here):
>>
>> - They express a certain "processing state" of a document.
>> This is related to, but not the same as the workflow state.
>> I see a conceptual confusion here.
>>
>> "authoring/foo" is another document than "live/foo". It
>> may be that both documents exist at the same time.
>> When speaking in workflow terms, the "authoring"
>> document has a workflow (it is in the "live" state),
>> the "live" document doesn't.
>>
>> Up to here, it's a little confusing, but not a real problem.
>> But what if we introduce a "staging" [1] repository?
>
>
> I suggest that Lenya uses some predefines states (e.q. authoring,
> staging, live, archive) .
IMO this is too rigid. Why should this be useful?
> I would define these four as mandatory for the
> application to work properly. If a set-up needs another additional state
> (e.q. "Staging for the CEO", "trash") it should be possible for the
> implementator to add it.
>
> I'm not quite sure, if a document can exist in all states at the same
> moment or if there are only some predefined combinations.
ATM a document can only exist in one state at a time
(state machine concept). But I guess Michael will come up
with a proposal for multiple workflow instances per document
soon.
> However, I
> think the idea to create a respository for each state is a good.
Why? I don't see the purpose of a relation between
workflow state and repositories.
>> Let's
>> imagine the following scenario. The first term in the
>> parenthesis is the repository (authoring, staging, live),
>> the second is the workflow state (edited, ready).
>>
>> 1) create new document
>> (authoring, edited)
>>
>> 2) submit
>> (staging, ready)
>>
>> 3) publish
>> (staging, published)
>> (live, [none])
>
>
> Maybe we need a definition of the terms. Here's my suggestion:
The workflow terms are already defined:
http://localhost:8080/lenya/docs-new/docs/components/workflow/terms.html
> Workflow = Describes the lifecycle of a document
> Workflow state = A defined state of a document within it's workflow
>
> Workflow action = The transition from one workflow state to another
> (aka steps) or a transition within the same
> workflow state
Action = Transition might be confusing, because the term
"action" has another meaning in automata theory (which the
Lenya workflow is based on).
> For states use adjectives like authoring, staging et cetera
> For actions use verbs open, edit, modify, delete, done et al.
This could be a useful recommendation.
> Also, like with the states mentioned above, I suggest, that there are
> some predefined and mandatory actions.
Why?
> Done - in my opinion - is such a
> mandatory action. You should avoid a action like "none", because each
> document has at any moment a well defined state, a known action who put
> it there and several opportunities as next steps.
>
>> Maybe someone has an idea how to improve this situation?
>> I have the feeling that we should stronger decouple
>> workflow states from repositories.
>
> What's the gain from the decoupling?
- conceptual purity
- more flexibility
- separation of workflow and repository concerns
>> My first idea is to use a common workflow instance
>> for all "incarnations" of a document in different
>> repositories. A workflow instance wouldn't be assigned
>> to a document, but rather to a document "group".
>>
>> We could also reconsider the term "document":
>> A document would be the union of all incarnations.
>>
>
> Good point. What is a document? I would define it like that:
>
> All information relevant for the publication of the document.
This might be confusing. The information relevant for the
"publication" (publishing?) of a document involves its
location, site structure dependencies, etc. which I wouldn't
assign to the document itself.
> This means
> all contents like title, body, notes. All assets like links, images,
> sounds et cereta.
Rather "references to ..."
> And all meta-information like keywords, author,
> modification date et cetera.
> In certain cases also the different
> language versions may belong to one document.
This issue has to be discussed.
> However, I don't have an
> idea at the moment how to solve the problem with translations which
> leads to new states not needed in every language.
What do you mean here?
Thanks for your comments!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org