[Pipet Devel] Universal Description, Discovery, and Integration

[Alexandre Fayolle]

On Fri, 3 Nov 2000, jarl van katwijk wrote:

> 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? I know we can stream
> stdout and stdin data, we can build many 'templates' for a N number of
> applications, but this will die a very chaotic death I'm afraid. I myself dont
> know
> what the best approach is to this XML patterning Piper will use. I'm very much
> interested in your comment.

Hello, 

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... 

To sum it up, I think what best applies to your problem is Narval's
concept of an action. An action has two parts: and XML prototype and a
python stub which will implement the action (or act as a proxy to
the Real Thing). The prototype can be viewed as a contract, that is: the
action garantees that if it is given the input it requires, it will return
the output specified in the prototype (otherwise, it's an error).

The DTD for an action is the following:

<!ELEMENT action (description*,input*,output*)>
<!ATTLIST action name CDATA #REQUIRED>
<!ATTLIST action func CDATA #REQUIRED>
 The name attribute is what you expect, the func attribute is the name of
the python stub (with the packages prefixed).


<!ELEMENT description (#PCDATA)>
<!ATTLIST description lang CDATA #REQUIRED>
Mostly GUI stuff.

<!ELEMENT input (match*)>
<!ATTLIST input optional (yes|no) "no">
<!ATTLIST input use      (yes|no) "no">
<!ATTLIST input list     (yes|no) "no">
This describes an Input: if the input in set optional, the action will be
run event if no matching elements are found. If the list attribute is set
to 'yes', then several matching elements can be passed to the action, and
if use is 'yes', an element will not be used twice for this action in two
consecutive executions of the recipe.

<!ELEMENT output (match*)>
<!ATTLIST output optional (yes|no) "no">

For outputs, specifying optional='yes' will not cause an error if no
matching element can be found in the output of the action.

<!ELEMENT match (#PCDATA)>
The match element really is an XPath. An input (or output) can have
several match children, and an element must match all the XPaths in order
to be considered valid as an input (or as an output). 

Cheers.

Alexandre Fayolle
-- 
http://www.logilab.com 
Narval is the first software agent available as free software (GPL).
LOGILAB, Paris (France).