RE: [ACTION-50]: Explain process triggers in more detail

Hi Pedro, all,

Two notes:

a) ‘contentFormat’ could probably use a MIME type instead of an ad-hoc list? This doesn’t prevent the use of custom values since one can have private MIME types.


b) 'processRequested' 

> A priori, the values could be user defined, since it is hard
> to generalize a set or combinations of actions for specific
> workflows. Some examples are: HTrans-HRev-LOC: this content 
> needs to be human translated (Trans) and human revised (HRev)
> and localized (LOC)

I would think user-defined values wouldn't be helpful. For example a CMS system may want to trigger a process for several languages to two distinct vendors (e.g. one dealing with most target languages, the other handling Arabic and Hebrew). Those distinct vendors may use distinct toolsets. It would be better if all three parties used a single set of values for processRequested.

Also if the CMS user decides to change vendor or add one, she doesn't want to set different values to trigger a process to the new vendors. And conversely, a vendor does not want to have to create mapping table for each CMS customer he has.

If we have a standard container to hold the information about the process requested it stands to reason that the values it contain are also standardized (at least to a minimum).

Here, like for domain, I think there is probably a simple set of value that can be defined and use as a standard. And maybe for additional more specialized or custom tasks, a secondary label could be used.

Sorry to be annoying with this issue of using standard values with lists, but from my experience with XLIFF and other standard formats allowing those types of "loose" metadata has been a major cause of non-interoperability. I'd like to see us avoid that trap.

One last note for processRequested: it may be better to use a space to separate the different task identifiers than a '-', so you could use '-' inside the identifier. Each task identifier could be of type NMTOKEN and processRequested of type NMTOKENS.

Cheers,
-yves

Received on Friday, 13 April 2012 14:27:30 UTC