Re: New static error: options in the XProc namespace

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Norman Walsh wrote:
|> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
|> | (1) I don't understand the difference between the context position
|> | (exposed through position()), $p:position and $p:stepname_index. When
|> | does $p:stepname_index differ from $p:position?
|>
|> Does this example help?
|>
|>   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0156.html
|
| I had looked at that, and didn't understand that before I didn't
| understand the wording in the spec. I also note that your explanation
| seems to be different from Mohamed's, which makes me think that
| there's a certain amount of confusion over these variables.

Perhaps.

|> In brief, what's exposed to the steps inside a for-each or viewport
|> isn't a sequence. Instead, the for-each feeds each each document in a
|> sequence that *it* receives to the inner steps, one document at a time.
|>
|> So (directly) inside a for-each, the $p:position is always 1. There's
|> never a "second" document because it's not a sequence.
|
| If $p:position is always 1, why have $p:position?

Position is always 1 in for-each and viewport because they're odd cases.
Consider this example instead:

<p:matching-documents>
  <p:input port="source">
    <p:inline>
      <odd/>
    </p:inline>
    <p:inline>
      <even/>
    </p:inline>
    <p:inline>
      <odd/>
    </p:inline>
    <p:inline>
      <even/>
    </p:inline>
    <p:inline>
      <odd/>
    </p:inline>
  </p:input>
  <p:option name="test" value="$p:position mod 2 = 1"/>
</p:matching-documents>

It returns all the "<odd/>" documents.

I think this example also illustrates why it would be a mistake to
overload XPath's built-in position() function. A complex expression
might use position() in a more natural context and it would be confusing
(though I grant not explicitly illegal) to have position() used in two
different ways in the same expression.

|> Compare that with $p:stepname_index which counts the interations of
|> the for-each or viewport loop.
|
| If you reference the index of a for-each nested within a for-each,
| does $p:stepname_index give the total number of iterations, or does it
| reset to 1 when the outer for-each moves on to its next document?

I believe it should reset to 1 each time.

|> I suppose we *could* use position() but I think it would be wrong.
|
| I strongly disagree. XPath has the concept of an environment which

I still think it would be wrong. Not only for the reason I gave just
above but also because it might encourage people to believe that they
could use last() and the streaming folks explicitly don't want to have
to support that.

|> | Finally, I observe that, should we want to, we can define functions
|> | that degrade elegantly when used out of context, whereas variable
|> | references that refer to variables that don't exist will always raise
|> | an error.
|>
|> I worked around that editorially by making sure that these variables
|> always have a value.
|
| Doesn't that mean that implementations have to parse XPaths to know
| what variable bindings to supply to the XPath engines they're using?

Uhm. I just supply all the ones that could be referenced. There are only
n+2 of them, where n is the depth of nesting of compound steps.

| Yes, that explains why the $myval variable reference doesn't get
| replaced when the XSLT stylesheet is constructed, but the comparison I
| was making was with:
|
|   <p:option name="replace" value="$myval" />
|
| Again, option values are considered "quoted": if you want to set them
| dynamically you use the select attribute rather than the value
| attribute.

I don't think that's quite right. You use select if you want to
calculate their value dynamically. That's independent of how the *step*
actually uses the value.

| However, in both cases we have a decision to make about which
| variables are bound in the environment in which the stylesheet or
| XPath is evaluated.

Indeed.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The Future Begins Tomorrow!--Yoyodyne
http://nwalsh.com/            | Propulsion Systems