[kepler-dev] Automatic output port generation in RecordDisassembler

[Edward A. Lee]

I like the idea of giving a template parameter to RecordDisassembler.
This could be set equal to a model parameter, which could be used then
by other actors as well to ensure consistency across the model.

Edward


At 11:14 AM 11/15/2007, Dan Higgins wrote:
>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
>*******************************************************************
>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

------------ 
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html