Re: Extension functions

On 5/23/07, Norman Walsh <ndw@nwalsh.com> wrote:
> I think we've already concluded (in email, at least) that the
> p:index() function isn't necessary. You can always use the position
> function to get the loop index, store it in an option, and then refer
> to that option.
>
> Jeni has convinced me (at last :-) that it's not unreasonble to use
> the standard XPath context function position() to represent the number
> of a document in a sequence.
>
> There was strong resistance to supporting last() because of its impact
> on streaming, so I propose that we say that the context size is always
> equal to the context position.
>
> The last function we have is p:episode(). Given that its value is
> constant throughout the evaluation of a pipeline, I'm inclined to say
> that steps don't have to be able to evaluate this function. Users can
> still make it available to steps by constructing it inside a select
> expression at the pipeline level or by storing it in an option.
>
> So it seems to me that we can say that the interface between a
> pipeline and a step is that it configures the XPath context in a
> particular way, exposing in-scope options as variable bindings and
> establishing the position and size of the context. We don't have to
> expose any extension functions to the steps.
>
> Anyone disagree?

Partially.

I don't see any value in exposing in-scope *options* as variable bindings
as our use of options and their values aren't going to help select
content.

I could see exposing in-scope *parameters* as variable bindings as
long as in-scope parameters means those parameters calculated
for the compound step's contained steps.


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Wednesday, 23 May 2007 19:57:12 UTC