Re: New static error: options in the XProc namespace

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