Re: some more thoughts

/ James Fuller <james.fuller.2007@gmail.com> was heard to say:
| a few more thoughts;
|
| a) declare-step and improving reuse
|
| Take the following example;
|
| <p:declare-step type="p:rename">
|     <p:input port="source"/>
|     <p:output port="result"/>
|     <p:option name="match" required="yes"/>
|     <p:option name="name" required="yes"/>
| </p:declare-step>
|
| would be nice to be able to define default values for a declared step ala.
|
| <p:declare-step type="my:rename" inherit="p:rename">
|     <p:option name="name" required="yes" value="test.txt"/>
| </p:declare-step>

I think that's unlikely to make it into V1. Note that you can do it
yourself "the long way":

<p:pipeline-library namespace="xxx">
<p:pipeline name="rename">
  <p:input port="source"/>
  <p:output port="result"/>
  <p:option name="match" required="yes"/>
  <p:option name="name" value="test.txt"/>
  <p:rename>
    <p:option name="match" select="$match"/>
    <p:option name="name" select="$name"/>
  </p:rename>
</p:pipeline>
</p:pipeline-library>

| b) versioning pipeline libraries and steps

Yeah, we need a versioning story. I won't attempt to predict where
that goes :-)

| c) p:journal feels like p:log to me

Yes, I can see that. I'm not personally motivated to change it though.
How strongly do you feel about it?

| d) any chance of a default p:wait step that just does nothing for a
| period of time?

What do you propose as its signature?

I will have need for that too, at least for testing when I start
working on threading. I'm going to be tempted to implement it myself
as an extension attribute on p:identity.

| perhaps you should consider some aliases for input and output elements
| (e.g. in and out) and just use x for namespace prefix I think it would
| improve readability. Don't waste anytime responding to this, silence
| will do as a vote in the negative.

I can't resist. I've never heard the argument that too many words with
a particular consonant decreased readability, but I know for sure that
languages that use abbreviations are harder to learn (is an input
spelled 'in' or 'inp' or 'input'?). We agreed to address this problem
with a simple rule: no abbreviations. It's been a fine rule and I'm
confident there would be no support for changing it no matter how many
of us wish we could spell parameter "param". :-)

And of course, you're free to use whatever prefix you want, even none.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.