[kepler-dev] custom actor MOML question

Paul Allen pea1 at cornell.edu
Thu Mar 12 09:05:13 PDT 2009


Thanks Matt. I think I understand what you are saying as well as 
Edward's bigger picture thoughts.

So could somebody show me the place in Kepler code that I could hook 
into to get functionality similar to ptolemy.moml.MOMLParser? I've tried 
to trace the Kepler startup code, but it's opaque to me. I especially 
don't understand how those special "kepler:" properties get stripped off 
when starting up org.kepler.loader.Kepler with the -nogui flag since it 
appears to directly call ptolemy.actor.gui.MoMLSimpleApplication which 
presumably doesn't do anything special with those "kepler:" properties 
(since it is pure ptolemy code).

Thanks.

Matt Jones wrote:
> Hi Paul,
>
> Kepler stores a variety of things in the MoML document that ptolemy
> does not, including documentation for entities and ports, semantic
> types for entities and ports, and other things.  For a variety of
> reasons, which I could go into in more detail if I chat with Chad a
> bit, the MoML parser does not deal well with these uses, even though
> they are syntactically valid MoML.  Turns out that the MoML parser has
> expectations that are not declared in the MoML DTD itself (such as
> that there can be no representation in MoML of a port defined in Java,
> else the MoML parser will not be happy).  The bottom line is that
> Kepler stores an extended version of MoML, but strips out these
> extensions before passing the documents onto the ptolemy MoML parser
> (much of this is handled in the core module under
> objectmanager.ActorMetadata and the org.kepler.moml package).  So if
> you are not using Kepler to do your parsing, you'll find that the
> ptolemy MoML parser chokes on Kepler's MoML (even though it is
> syntactically valid).
>
> I realize this is not an ideal solution for our extensions because it
> breaks compatibility with ptolemy.  We've discussed various
> alternative approaches to representing the extensions we need -- such
> as MoML-based semantic types for all ports (whether defined in moml or
> in java).  Is there a reason your tools can't use Kepler to do the
> parsing for now? Hope this helps,
>
> Matt
>
> On Wed, Mar 11, 2009 at 11:53 AM, Paul Allen <pea1 at cornell.edu> wrote:
>   
>> Could somebody explain why Kepler adds a "kepler:" prefix to the port names
>> in my custom actors when I instantiate the actor by class name and then save
>> the kar for that component via the Kepler GUI? That change is confusing some
>> downstream tools I'm using mainly because the port names in the <link>
>> section of the MOML don't use the "kepler:" prefix.
>>
>> Here's the MOML from the KAR for the actor.
>>
>> <?xml version="1.0"?>
>> <entity name="GoogleBarChart" class="ptolemy.kernel.ComponentEntity">
>> <property name="entityId"  value="urn:lsid:sciencepipes.org:actor:1:1"
>> class="org.kepler.moml.NamedObjId"/>
>> <property name="class" value="edu.cornell.birds.is.bap.actor.GoogleBarChart"
>> class="ptolemy.kernel.util.StringAttribute">
>>  <property name="id" value="null"
>> class="ptolemy.kernel.util.StringAttribute"/>
>> </property>
>> <property name="kepler:url" class="org.kepler.moml.PortAttribute">
>>  <property name="direction" value="output"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="dataType" value="string"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="isMultiport" value="false"
>> class="ptolemy.kernel.util.StringAttribute"/>
>> </property>
>> <property name="kepler:title" class="org.kepler.moml.PortAttribute">
>>  <property name="direction" value="input"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="dataType" value="unknown"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="isMultiport" value="false"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  </property>
>> <property name="kepler:secondary title"
>> class="org.kepler.moml.PortAttribute">
>>  <property name="direction" value="input"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="dataType" value="unknown"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="isMultiport" value="false"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  </property>
>> <property name="kepler:values" class="org.kepler.moml.PortAttribute">
>>  <property name="direction" value="input"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="dataType" value="unknown"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="isMultiport" value="false"
>> class="ptolemy.kernel.util.StringAttribute"/>
>> </property>
>> <property name="kepler:labels" class="org.kepler.moml.PortAttribute">
>>  <property name="direction" value="input"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="dataType" value="unknown"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="isMultiport" value="false"
>> class="ptolemy.kernel.util.StringAttribute"/>
>> </property>
>>
>> <property name="height" class="ptolemy.data.expr.Parameter" value="240">
>> </property>
>>
>> <property name="width" class="ptolemy.data.expr.Parameter" value="240">
>> </property>
>>
>> <property name="show zero" class="ptolemy.data.expr.Parameter" value="true">
>> </property>
>>
>> <property name="orientation" class="ptolemy.data.expr.StringParameter"
>> value="horizontal">
>> </property>
>>
>> <property class="org.kepler.sms.SemanticType" name="semanticType00"
>> value="urn:lsid:localhost:onto:1:1#ExternalGraphicalOutputActor"/>
>> <property class="org.kepler.sms.SemanticType" name="semanticType11"
>> value="urn:lsid:localhost:onto:2:1#TextualOutput"/>
>>
>>
>> <property name="_location" class="ptolemy.kernel.util.Location"
>> value="[260.0, 60.0]">
>> </property>
>>
>>
>> </entity>
>>
>> I've attached the MOML for the model in question.
>>
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>>
>>     
>
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20090312/c096abc4/attachment.html>


More information about the Kepler-dev mailing list