[Pipet Devel] Universal Description, Discovery, and Integration

[Brad Chapman]

Jarl:
> > I have something else that worries me more, let's keep up the 
> > atmosphere and call it the pattern problem. It's about how to 
> > represent the executables. How will
> > we layout the XML that describes the applications? 

Alexandre: 
> Maybe you could give a glance at what we have for Narval. I don't think it
> will apply to your architecture, but it may give you ideas... 
[very nice description of Narval's way of describing actions/nodes]

Jarl, what we have been using so far for describing actions in Piper
is a combination of what we had in Loci combined together with the way 
Overflow handled things. Basically, this is also very similar to the
way things are done in Narval.


I wrote some documentation (now out of date, of course) about how this 
works, which can be found at:

http://www.bioinformatics.org/piper/documentation/piper_plugin.pdf

Although this is not really accurate with how things are currently
(mostly we changed from using the name locus to describe an action to
using the name NodeClass), it gives the general picture of how things
works. The current DTD, with all of the current correct information,
can be found in cvs in dtd/locusPlugin.dtd.


Basically, a NodeClass (which seems analagous to a Narval action) has
inputs and outputs, which look like:

<!ELEMENT Input (#PCDATA)>
<!ATTLIST Input
   name CDATA #REQUIRED
   type (VALUE | STREAM | OBJECT | CONDITION | STRING | ANY) "ANY"
   xlink:href CDATA "none"
   expand (yes | no) "no"
   opt (optional | mandatory) "optional">

o The type attribute specifies, as the name suggests, the type of input
that is represented. This is kind of a quick-n-dirty way of verifying
inputs and outputs match up, and is borrowed from the way overflow
works. I admit this is not ideal, but was at least a starting point to 
work from.

o The xlink will point to the output that the input gets linked to.

o The expand attribute, if set to yes, will allow an Input to be
"duplicated" within a Node, so that you could have an input that could 
take an arbitrary number of connectors (this seems analagous, in
spirit, to Narval's list attribute).

o The opt attribute describes whether or not the input has to be set
for the Node to work properly.


Piper also has an additional Parameter attribute, which I didn't see
an analogue of in Narval. This looks similar to an input or output:

<!ELEMENT Parameter (#PCDATA)>
<!ATTLIST Parameter 
   name CDATA #REQUIRED
   type (VALUE | STRING | BOOL| INT | FLOAT | SUBNET_PARAM | ANY) "ANY"
   value CDATA "none"
   expand (yes | no) "no"
   opt (optional | mandatory) "optional">

The idea of Parameters are "borrowed" from the UNIX command line, so
that Parameters are supposed to be like command line options. So
inputs and outputs describe the information that passes in and out of
a Node, and the parameters can affect how the Node processes the
inputs to produce the outputs.


I hope this is the kind of answer you were looking for and helps
some... My apologies it took me so long to write on this.

Brad