Re: New static error: options in the XProc namespace

Norman Walsh wrote:
> Two things:
> 
> First, it seems to me that the step has to update the context position
> as it iterates through the sequence and I don't see how that's any
> different than updating the p:position().

The difference is in who has control. In my view of the world, when a 
XProc processor invokes a component, it passes in a set of information 
and the component uses only that information in order to produce a 
result. The component surely shouldn't need to know that it's been 
invoked by a XProc processor. So the variable bindings provided by XProc 
cannot change during the course of running the step. Functions can't do 
a call back to find out what's going on in the XProc context (though the 
implementation of an extension function might be different depending on 
the context in which it's called).

And if there is no difference, then why not use the existing, known and 
understood position() function rather than a new, under-defined and 
confusing p:position() function?

> Second, while all of the off-the-shelf XPath processors that I've looked
> at offer some mechanism for calling extension functions (or setting
> variables, though we've opted not to go that way, I think), I'm much
> less confident that they provide a mechanism for changing the internal
> context position.

Well, Jaxen has a Context.setPosition() method so you could use that. In 
any case, I would far rather our spec be led by the interface to XPath 
defined in the XPath Recommendation than by the current state of 
off-the-shelf XPath APIs.

> While I concede that the number of documents can be seen as the context
> position in one sense, I remain of the opinion that that's not very
> XPath-1-like and would prefer to use an extension function.

(I didn't say that the number of documents should be the context 
position. I said that the position of the document in the sequence of 
documents should be the context position. The context *size* should be 
the number of documents.)

I really don't grasp your objection. The situation we're talking about 
is exactly analogous to:

  <xsl:for-each select="document('a.xml') |
                        document('b.xml') |
                        document('c.xml')">
    ...
    <xsl:value-of select="position()" />
    ...
  </xsl:for-each>

Within the <xsl:for-each>, the position() function tells me the position 
of the document in the sequence being processed (yes, I know the XPath 
produces a node-set, but for-each iterates over it as a sequence) and 
last() tells me how many documents there are in the sequence.

How is this not very XPath-1-like?

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 23 May 2007 12:45:38 UTC