I wrote: >> <!--Constant.xml >> Locus type describing a constant value. >> --> Jean-Marc wrote: > I would remove this comment and put it in the definition so it can be used from > Piper Ooops, yeah, I meant to do that. Sorry! Jean-Marc wrote: > I suggest something like: > <piperplugin> > <locus name = "Constant" module="General"> > > <parameter name = "constant_value" type = "ANY" /> > <output name = "output_constant" type = "ANY" /> > <comments> Locus type describing a constant value. </comments> > </locus> > </piperplugin> > > If each node definition is in its own XML file, the module name can just be a > property. This all looks great, although I'm not sure about the module thing just because you could have multiple levels of module organization within a top level category. For instance, sticking with UNIX examples, you could have: unix/utilities -> for stuff like ls, grep unix/processes -> for process associated stuff like kill, nice just as an example. We could also do this with module = "unix/utilities" or module = "unix.utilities" What do you think? > Also, this is just a detail, but I suggest not to use a .xml > extension > since most of the piper files will be XML files. I agree, I just didn't have enough brainpower to think up a good extension. Any ideas? random.pip? random.ppr? random.brad? [...snip...xml for ls...] > I may be missing something, but that seems to be too compilicated and I don't > see the gain. I guess the major gain is just that we can deconstruct the "built" node back into its individual components, so it could be modified and then "re-built." There may be better ways to accomplish this goal (or maybe this isn't even a good goal?). What were your thoughts on how 'ls -l' would look considering how the individual loci look? Brad