[kepler-dev] Automatic output port generation in RecordDisassembler

[Dan Higgins]

Hi Ilkay,
    I got thinking about this issue after our last REAP call and thought 
I would try to summarize some thoughts here.

    At design time, actors are really independent. Most of the actors 
that dynamically generate output ports are data source actors. Except 
for trigger inputs, there are no inputs and the output ports can be 
generated because the actor uses some parameter to get the data needed 
to generate ports when it is instantiated (i.e. dropped on the canvas) 
or input parameters are changed. [Example: EML2 Datasource uses the eml 
metadata, the OpenDAP actor uses a URL; Changing an actor parameter 
during design will trigger changes in the output ports due to 
AttributeChanged events.]

    But the actor connected to the output of a Data Source only gets 
port data from the preceding actor during the fire cycle which doesn't 
occur during design. Say some data source puts its output in a complex 
form (e.g. a Kepler Record or XML or an R dataframe). If that output is 
connected to the input of another actor, without additional information, 
the following actor cannot know any details of its input until it 
receives the datatoken! The existing RecordDisassembler works by 
requiring the user to know some 'names' of items in the Record token and 
creating output ports with that name.

    Now, a RecordDisassembler actor could be given a Parameter that is 
an array of strings that are names of Record elements and then could 
automatically generate output ports based on that array (or it could be 
given a 'template' RecordToken and figure out the name array from the 
Token). A change in this parameter at design time would trigger changes 
in the outputs. The parameter could even be placed on the canvas and 
shared between multiple actors. (i.e. Parameters are a way for actors to 
share information at design time).

    Note that the problem is related to complex data types like a Record 
or XML file. The data type of ports can be set at design time and 
checked. But with complex types, the type itself is incomplete (i.e.more 
information is needed). For a Record, one would really need a complete 
description of the Record with element names and element types (perhaps 
recursive) and with XML, one would need a complete schema. Requiring 
such complete type descriptions would make actors so specific that their 
usefulness would be limited to only a few cases.

    Theoretically, one could have an actor query everyone of its 
predecessors when its input ports were connected to see if there is 
information about the details of the data that will be sent to it (e.g. 
a RecordDisassembler could ask its predecessor(s) for a prototype 
record) and use that data (if available) to configure outputs. But that 
greatly increases the complexity of a workflow because every actor is 
then (possibly) strongly linked to all of its predecessors!

    So all this brings me to one possible solution. Assume that any data 
source that actually gets information at design time (like the EML of 
the EML actor or the OpenDAP actor) ALSO created a Kepler parameter when 
it was dropped on the canvas (or its parameters were changed) and this 
new parameter were automatically made visible on the workspace canvas. 
The parameter would basically be the schema of the Record or EML that 
the actor might output. Any other actor added to the model could then 
use that parameter. e.g. if the parameter were a Record, a 
RecordDisassembler could use it as a template for creating outputs.

Comments and discussion always appreciated.

Dan

----



Ilkay Altintas wrote:
> Hi,
>
> I'm interested in generating a RecordDisassembler that can get the  
> names of the record parts from the downstream actor and create its  
> output ports automatically.
>
> Currently this is not possible as the data type for the record input  
> port is unknown until run time. I was wondering if there is a quick  
> method where I can get it to have the information I need to create  
> the ports by invoking a method at design time. Or do you know a  
> better way to implement this?
>
> Any help would be appreciated...
>
> Thanks!
> -ilkay
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>   


-- 
*******************************************************************
Dan Higgins                                  higgins at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Ph: 805-893-5127
National Center for Ecological Analysis and Synthesis (NCEAS) Marine Science Building - Room 3405
Santa Barbara, CA 93195
*******************************************************************