RE: [all] Discussion on proposed metadata categories: approvalStatus

Dave, I think it is clear to me:

 

processTrigger provides the basic parameters to activate a certain
localization process of the source content, while processState and
provenance indicate a certain result (state or provenance) of the target
contents.

 

In this respect, the control could be done crossing info about the
“requested” (processTrigger) and the results (processState and provenance),
but this is already a functionality that belongs to the CMS and I agree out
of scope.

 

Best,

Pedro

 

  _____  

De: David Lewis [mailto:dave.lewis@cs.tcd.ie] 
Enviado el: viernes, 27 de abril de 2012 1:13
Para: "Pedro L. Díez Orzas"
CC: public-multilingualweb-lt@w3.org
Asunto: Re: [all] Discussion on proposed metadata categories: approvalStatus

 

Pedro,
Yes, the redundancy of process state is one outcome of what I'm proposing
here.

The key difference is that the proposal is that the data category indicates
the next process that should be performed, rather than indicating the
current process in operation. The motivation is that the readiness to
undergo a new process step is more useful to a document in a CMS, then
knowing the current state that is operating on it.

Complementary to this, provenance indicates that a process is completed, and
associated with this records useful information needed to monitor correct or
efficient process operation, perhaps as needed to monitor a service level
agreement.

Neither process trigger or provenance however actually aim to control
process flow. This is a complex topic which therefore is probably out of
scope. 

What we do need however, is a way of defining  the values to use for
referencing processes, i.e. from both the 'request-process' and the process
reference in provenance. For this we may want both a default set in the
standard, and a way of unambiguously defining these for a particular
business case. The key thing in any one case of interoperability is that the
interoperating implementations exchange and understand the _same set_ of
process values. 

let keep the discussion going on the list,
Dave

On 26/04/2012 15:29, Pedro L. Díez Orzas wrote: 

Hi David,

 

I need to consider this more carefully. 

 

But, what I see is that process state is perhaps redundant with:
proofreading state or revision state, since these can be values of process
state: proofreaded, revised, reviewed, translated, localized…

 

Best,

Pedro

 

  _____  

De: David Lewis [mailto:dave.lewis@cs.tcd.ie] 
Enviado el: jueves, 26 de abril de 2012 1:52
Para: public-multilingualweb-lt@w3.org
Asunto: Re: [all] Discussion on proposed metadata categories: approvalStatus

 

Hi Moritz,
I think you make a very good general point here. It may be a bit too open
ended to specify data categories that hardwire the completion of a specific
step. We would run into the same issues we have with defining the different
process values as we discussed around process trigger. Also, its not clear
to me that all status flag suggestion for current steps, e.g. legal
approval, really need to be separated from other steps.

I think therefore we could generalise this as part of the process trigger
data category as you suggest. This could allow us to consolidate
approvalStatus, cacheStatus, legalStaus, proofReading state and revision
state (and delegate the definition of these steps to data values rather than
individual data categories). We can address cacheStatus, and at he same time
generalise it to other processes than just translation, by including the
time stamp and a revision flag. 

Also, I think the priority data category should be included here, as
translation could consist of many different processes in combination, so it
semantics are dependent on which one. At the same time we may also be
interested in defining priorities even for non translation activities, such
as review.

requested-process (which has the name of the next process requested)

process-ref (which may allow us to point to an external set of process
definitions used for processRequested if the default value set is not used)

ready-at (defines the time the content is ready for the process, it could be
some time in the past, or some time in the future - this support part of the
cacheStatus function)

revised (yes/no - indicated is this is a different version of content that
was previously marked as ready for the declared process)

priority (I think for now we should keep this simple and just have values
high/low )

complete-by (provides a target date-time for completing the process)

Any thoughts on this suggestion. Pedro, Ryan, Moritz, Des, I think this
impacts on data categories you have an interest in.

Also, DavidF, Pedro, Ryan, do you think this makes process state redundant?
As a status flag are we more interested in what process to do next, rather
than which one is finished. At the same time the provenance data category
could tell us which processes have already finished operating on the
content. 

cheers,
Dave


On 24/04/2012 11:11, Moritz Hellwig wrote: 

to identify publication process metadata which might also be relevant for
the LSP. I ran into a couple of questions though.

 

I’ll use approvalStatus as an example (from the requirements document):

>> approvalStatus 

>> Information about the status of the content in a formal approval workflow

>> Indicates whether the content has been approved for release 

>> Possible values:

>>>> yes

>>>> no

 

Approval can have many values which are rarely only “release yes|no” and
they can be client/application-specific. However, none of these statuses
seem to be relevant to the LSP, as they only precede or succeed the LSP’s
processes.