document status flags [was: Re: Document Gestation Process?]

[Diana Shannon <sh...@terracare.com>]

On May 1, 2002, Steven Noels wrote:

>
>> Is there a way to flag something as:
>>
>> 1. work-in-progress (cron reports what work still needs to be done)
>> 2. in QA (cron reports what is still in QA - QA can knock it
>> back down
>> to editorial/work-in-progress)
>> 3. certified to be generated into docs (cron job picks these up to
>> generate the site)
>
> Nope, no flags yet - but a very good idea.
>
> I would think we would use CVS branches for that - opinions?

Extending Rob's idea, don't we need internal flags (attributes/elements) 
within docs themselves to indicate status/stage of evolution (not simply 
version)? This allows all kinds of grouping/filtering/display options to 
aid project management. For example, a user interesting in providing QA 
can go to a page which shows all docs ready for usability tests. A 
coordinator may want to examine the status of all docs in process. A 
contributing author may want a list of docs with "fix-me" holes in 
drafts or outlines. In other words, isn't it more flexible to generate 
status reports by applying transformations to the docs themselves, 
instead of by cron jobs/cvs?

I assumed CVS branches come in to play when document is either in 
process (in head) or finished (in release). Am I overlooking other 
features of cvs branches? I guess I'd also prefer to apply a Cocoon 
solution to project management, however primitive it may be at the 
outset.

Diana


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

Re: document status flags [was: Re: Document Gestation Process?]

[Diana Shannon <te...@mac.com>]

On May 1, 2002, Steven Noels wrote:

> As far as visualizing process and state is concerned, metadata stored
> inside the documents are a valid option, and we haven taken this in
> account for our 'book.xml-nuker' Generator we are working on (to be
> released to Forrest, no commit rights over here). Basically, 'libre' as
> we will call it, is a DirectoryGenerator-on-steroids offering you the
> possibility to generate an XML listing of a (directory) hierarchy using
> a filtering mask based on regex and XPath expressions, sorting them
> using information gathered using regexes and XPaths, and providing
> labels for the traversed resources using them, too.

Fantastic!

>> I assumed CVS branches come in to play when document is either in
>> process (in head) or finished (in release). Am I overlooking other
>> features of cvs branches? I guess I'd also prefer to apply a Cocoon
>> solution to project management, however primitive it may be at the
>> outset.
>
> Just bear in mind that we have no live Cocoon instance to host such a
> thing, yet. We will have a test setup to generate static HTML that can
> be published on ASF servers however.

Well, theoretically, every distribution of Cocoon can be used 
dynamically. Just because Cocoon's live site is static-only doesn't mean 
we can't exploit more dynamic capabilities (like lucene) in what we 
could distribute/make available for content development/management aids.

Diana


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

RE: document status flags [was: Re: Document Gestation Process?]

[Steven Noels <st...@outerthought.org>]

Diana,

> On May 1, 2002, Steven Noels wrote:
>
> >
> >> Is there a way to flag something as:
> >>
> >> 1. work-in-progress (cron reports what work still needs to be done)
> >> 2. in QA (cron reports what is still in QA - QA can knock it
> >> back down
> >> to editorial/work-in-progress)
> >> 3. certified to be generated into docs (cron job picks these up to
> >> generate the site)
> >
> > Nope, no flags yet - but a very good idea.
> >
> > I would think we would use CVS branches for that - opinions?
>
> Extending Rob's idea, don't we need internal flags
> (attributes/elements)
> within docs themselves to indicate status/stage of evolution
> (not simply
> version)? This allows all kinds of grouping/filtering/display
> options to
> aid project management. For example, a user interesting in
> providing QA
> can go to a page which shows all docs ready for usability tests. A
> coordinator may want to examine the status of all docs in process. A
> contributing author may want a list of docs with "fix-me" holes in
> drafts or outlines. In other words, isn't it more flexible to
> generate
> status reports by applying transformations to the docs themselves,
> instead of by cron jobs/cvs?

I believe CVS is the only technical means of content management and by
coincidence process control we have currently. So eventually, all
documentation, regardless of what phase it is in, should reside in CVS
before we can act upon it.

As far as visualizing process and state is concerned, metadata stored
inside the documents are a valid option, and we haven taken this in
account for our 'book.xml-nuker' Generator we are working on (to be
released to Forrest, no commit rights over here). Basically, 'libre' as
we will call it, is a DirectoryGenerator-on-steroids offering you the
possibility to generate an XML listing of a (directory) hierarchy using
a filtering mask based on regex and XPath expressions, sorting them
using information gathered using regexes and XPaths, and providing
labels for the traversed resources using them, too.

> I assumed CVS branches come in to play when document is either in
> process (in head) or finished (in release). Am I overlooking other
> features of cvs branches? I guess I'd also prefer to apply a Cocoon
> solution to project management, however primitive it may be at the
> outset.

Just bear in mind that we have no live Cocoon instance to host such a
thing, yet. We will have a test setup to generate static HTML that can
be published on ASF servers however. Due to the caching issues one
encounters when traversing filesystem hierarchies, I'm not sure whether
we want this to be a dynamic process, anyhow.

</Steven>


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