Re: New static error: options in the XProc namespace

On 5/13/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
> 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?

position()                  the position of a node in a nodeset
$p:position                the position of the current (extracted)
document in the source sequence
$p:stepname_index   the position of the current (extracted) document
in the sequence of (extracted) document

example
(
<root>
  <b att="1"/>
</root>
,
<root>
  <b att="2"/>
  <b att="3"/>
</root>
)
in
<p:for-each select="//b" name="for-each">
</p:for-each>

you will have
in current consecutively

<b att="1"/>
with $p:position == 1 and p:for-each_index == 1

then

<b att="2"/>
with $p:position == 2 and p:for-each_index == 2

then

<b att="3"/>
with $p:position == 2 and p:for-each_index == 3


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

concur

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


Very interesting

Mohamed
-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Sunday, 13 May 2007 20:36:25 UTC