Kepler

Dynamic ReportItems (i.e. an actor's port) are referenced in the ROML and used to lookup the value[s] in Provenance.
In the case of an actor port, the Token value[s] that have passed through the port are used.

The assembler must handle the layout of multiple values (informed by configuration in the ROML), and also handle "by reference" tokens (i.e. images that have "values" that are simply pointers to the resource as it exists in some accessible system). When we get to the visual rendering stage of the report instance, those references will need to be available from outside the particular Provenance system that initially captured them during workflow execution. Perhaps these resources will be published to the "publication ready archive" or they will be pushed to an online file store (Metacat instance) and referenced via an LSID.

Handling the ROML -> RIO step should be in two stages:
-Local execution: Resources are referenced only in Provenance
-RIO export: Referenced items need to be "published" so that they are accessible for

The assembler need only deal with Java objects (making formatting decisions and looking up values from provenance). The formatting will all happen downstream once we have a fully-fleshed "ReportSpecification" object at the ready (post execution)

the assembler is in place.
it's up to the various Item subclasses to get their values when needed.

Original Bugzilla ID was 3647