Kepler

Looks like we'll want to be capturing the ROML, the RIO, and perhaps even the PDF version of the report. This will be similar to storing the MOML for each execution of the workflow.

Derik and I were talking about how the schema could accommodate more than just the MOML file. Currently there is a column on the WORKFLOW_EXEC table has a WF_CONTENTS_ID column to point to the MOML as it existed for that run (in the DATA table).
If we do want to store all these auxiliary files in the provenance store then....we'd need to support n* files for each execution. I think it's fine to store them in the same DATA table that is being used for all the other data (and moml file).
Would need to keep track of "file type" - this is more than just "is it a PDF?" - we'd need to know if, say, an XML file was a ROML or a RIO, etc...
If we did have 2 or more Report Layouts (ROML) for a given workflow execution - we'd need a way to distinguish them from each other (perhaps a name or other metadata about the particular layout).

I'm not sure we're completely committed to storing all these artifacts in the provenance store (it seems slightly orthogonal to the intent of provenance).

we do have all the file artifacts being inserted.
I note the comment about provenance storing things from plotting actors...we have tokens that they might consume, and if they emitted an image then we'd have them...but those actors are very GUI and not so image-file based

The provenance recorder is currently capturing all the data needed by reporting. Additional requirements can go in new bugs.

Original Bugzilla ID was 3649