Re: p:xslt

"Dave Pawson" <dave.pawson@gmail.com> writes:

> I can see the need... when I need them.
> Why are they 'required' and more importantly,
> when are they required.
> I can't see from the rec where it says any child element of p:xslt is required?

All inputs have to be connected.

    err:XS0032

    It is a static error if no binding is provided and the default
    readable port is undefined.

So you don't technically have to have any child elements as long as
the default readable port is defined. And you don't mind if all your
inputs are bound to that.

If you leave a parameter input port unbound, there are default rules
for that too. And if there's nothing for the default to bind to,
that's an error.

So, one of the following must be true:

1. You declared a parameter input port on your top-level pipeline.

2. You used p:pipeline to declare your top-level pipeline (this
   satisfies point 1 by default)

3. You provided an explicit binding for the 'parameter' input port on
   your p:xslt step.

>> Here's how it works.
>>
>> 1. If you don't specify a binding for the 'parameter' port, then it
>> binds by default to the parameter port of the pipeline that contains
>> it. This way, parameters you pass to the pipeline automatically get
>> passed to the steps that can use them.
>
> I got a failing pipeline to work, presumably binding to the pipeline
> 'default' parameter port.

Presumably.

>> 2. If there is no binding for a parameter input port on the top level
>> pipeline (the one that you start executing first), then it
>> automatically gets bound to an empty document.
>
> Ah. Thanks.
> OK. 5.1.2
> If no binding is provided for a parameter input port other than the
> primary parameter input port, then the port will be bound to an empty
> sequence of documents.
>
> Does that say the same as what you've just said?
> Note the 'other than the primary' bit?

Ok, the situation is actually a wee bit more complex. I was just
trying to keep things simple(er).

A step could define more than one parameter input port (though now
standard steps do). In that case, the defaulting rules for the primary
parameter input port (if there is one) and the non-primary ones are a
little different. The primary one gets bound back to the pipeline
parameters; the non-primary ones just get empty sequences.

>> 3. If you declare your pipeline with <p:pipeline>, you get a parameter
>> input port by default and things "just work".
>>
>> 4. But if you declare your pipeline with <p:declare-step>, as I usually
>> do, then you have to either remember to provide a parameter input port
>> explicitly:
>>
>>  <p:declare-step ...>
>>    <p:input port="parameters" kind="parameter"/>
>
> Is this the primary parameter port? ... due to it being the only one?

Yes.

> And it's bound to ... ? An empty sequence?
> Getting a bit convoluted Norm :-)

It's bound to whatever the implementation decides to bind it to. The
binding of top-level input ports to documents in the outside world is
implementation defined.

In Calabash, if you pass a binding for that port on the command line,
that's what it gets bound to. If you pass parameters on the command
line, Calabash manufactures a c:parameter-set with those parameters
and that's what it gets bound to. If you do neither of those, it gets
bound to an empty sequence.

>>    <p:input port="source"/>
>>    ...
>>
>> Or you have to remember to explicitly provide a binding when you use
>> the XSLT step:
>>
>>  <p:xslt>
>>    <p:input port="parameters">
>>      <p:empty/>
>>    </p:input>
>
> Different question.
> I started this to get a string back from p:system-property()
>
> Do I have to run an xslt step to obtain this?
> I.e. to use xpath?

That dpeends, what do you want to do with the string?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | So, are you working on finding that bug
http://nwalsh.com/            | now, or are you leaving it until later?
                              | Yes.