- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Sun, 13 May 2007 21:40:27 +0200
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Alessandro Vernet wrote: > On 5/11/07, Norman Walsh <ndw@nwalsh.com> wrote: >> No, I don't think so. I was mildly surprised during the call that the WG >> didn't find (F1) in favor of functions more persuasive. > > Then let's see if some of us who are reading this thread now and > didn't get a chance to attend the call last week have something to say > about this. And if nobody speaks up, I guess we'll proceed with > variables. Reading the spec, (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? When couldn't the value held in $p:position be more readily exposed through the position() function? (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). 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. (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"> <bar xsl:version="1.0"> <xsl:value-of select="$myval" /> </bar> </p:input> </p:xslt> </p:group> would you expect the variable binding from the XProc environment to be available in the XSLT environment? 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. 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> Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Sunday, 13 May 2007 19:40:37 UTC