Re: some more thoughts

On 6/7/07, Norman Walsh <ndw@nwalsh.com> wrote:
> / James Fuller <james.fuller.2007@gmail.com> was heard to say:
> | 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":

understand

> | b) versioning pipeline libraries and steps
>
> Yeah, we need a versioning story. I won't attempt to predict where
> that goes :-)

understand, I didn't see much visible discussion on this topic with
respect to XML Processing group.

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

not strongly,

a p:log type element would need some further discussion.....perhaps
p:log could have a life plugging into the generic logger concept. will
have a think

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

p:wait / p:sleep: simply waits for some duration, with below the first
best guess at signature

<p:wait hours="" minutes="" milliseconds="" />

* each value is additive to the amt of time to wait.

* could also see of something along the lines of p:suspend, that is to
wait until some event/action ....like an end user inputting some
secure credentials (user/pass)

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

yes perhaps it would be good to collect all such things into seperate
optional libraries, though perhaps there is a need to have a few such
libraries endorsed under Xproc.....

system: contain things like aforementioned wait e.g. system:wait

test: contain unit testing

this promotes modularity and keeps the core clean.

> | 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". :-)

this is definitely anecdotal and I agree with you with abbreviations
but would very weakly argue that most people would happily scan 'input
and output' to 'in and out' with no problems.

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

yes, was going to propose that the spec itself uses none and just have
everything live in the default namespace...I am fine with namespace
prefixes though when training others less xml equipped  it helps to
strip things down to a bare minimum and can make a spec much more
readable.

cheers, Jim Fuller

Received on Thursday, 7 June 2007 20:49:39 UTC