Re: New static error: options in the XProc namespace

/ 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

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.

Compare that with $p:stepname_index which counts the interations of
the for-each or viewport loop.

| When couldn't the
| value held in $p:position be more readily exposed through the
| position() function?

Because XPath 1.0 doesn't have the concept of a sequence. In XPath,
position() is a position in a nodeset and we don't have a nodeset.
We have a sequence of documents.

I suppose we *could* use position() but I think it would be wrong.

| (2) I do think that environment information should exposed through
| functions rather than variables, because that's how it's done in XPath
| and XSLT -- position(), last(), system-property(), current(),
| current-group(), current-grouping-key(), and regex-group() are all
| examples -- which will be familiar to our users. I also prefer using
| functions because it seems better to use function arguments than
| naming schemes (e.g. index(stepname) rather than $p:stepname_index).

I agree. You're the second person who would have voted for functions
instead variables if you'd been on the call. I wonder if that's enough
to turn the tide? (It would have been on the call.)

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

| (3) I think we need to take great care to distinguish between places
| where XProc uses expressions or patterns (where I'd expect option
| variables and environment functions or variables to be available) and
| places where arbitrary steps use expressions or patterns (where I
| wouldn't expect them to be available).
|
| For example, if I have:
|
| <p:group>
|   <p:option name="myval" value="foo" />
|   <p:xslt>
|     <p:input port="stylesheet">
<p:inline>
|       <bar xsl:version="1.0">
|         <xsl:value-of select="$myval" />
|       </bar>
</p:inline>
|     </p:input>
|   </p:xslt>
| </p:group>
|
| would you expect the variable binding from the XProc environment to be
| available in the XSLT environment?

No. From 3.3 in the spec:

  Inline documents are considered "quoted", they are not interpolated
  or available to the pipeline processor in any way except as documents
  flowing through the pipeline.

| Personally, I wouldn't: the only
| variable bindings that are available in the XSLT environment are those
| declared in the XSLT stylesheet, and to pass in other variable
| bindings, I have to use parameters.
|
| Now, if I have:
|
| <p:group>
|   <p:option name="myval" value="foo" />
|   <p:string-replace>
|     <p:option name="match" value="@class[. = 'bar']" />
|     <p:option name="replace" value="$myval" />
|   </p:string-replace>
| </p:group>
|
| This is exactly the same situation: the XPath expression held in the
| replace option is passed (as a string) to the p:string-replace
| component. The definition of the p:string-replace step says nothing
| about the variable bindings that are available, so I'd expect none,
| and for this invocation to fail because of a reference to an unknown
| variable.

Indeed. There's a hole in the spec now that Mohamed pointed out where
we don't say that $foo in an XPath expression is a reference to the
in-scope value of the option 'foo'.

But even that wouldn't cover this case because we don't say that those
option values are available *to the steps*, only to the XProc processor.

| I think we need some wording, in the definitions of those steps that
| use expressions or patterns, that says what variables and functions
| are available, as well as what the context node, position and length
| are. If option variables and environment functions or variables aren't
| automatically passed to these steps (and I don't think they should
| be), we need to specify that these steps use parameters to provide
| variable bindings for the step.
|
| In the latter case, I would write:
|
| <p:group>
|   <p:option name="myval" value="foo" />
|   <p:string-replace>
|     <p:option name="match" value="@class[. = 'bar']" />
|     <p:option name="replace" value="$myval" />
|     <p:parameter name="myval" select="$myval" />
|   </p:string-replace>
| </p:group>

Ouch. That seems really ugly. I think I'd rather say that steps can ask
the processor for the values of variables and functions. So the steps
that accept patterns can be documented that way. The XSLT step has no
knowledge of the pipeline processor so it naturally doesn't ask.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The universe that we observe has
http://nwalsh.com/            | precisely the properties we should
                              | expect if there is, at bottom, no
                              | design, no purpose, no evil and no
                              | good, nothing but pitiless
                              | indifference.--Richard Dawkins