RE: Default binding for variable, option, parameter definitions

+1 one from me. I have been facing exactly the same problems you
described. Especially explaining this to first time XProc users is not
easy.

I believe the main motivation for the current behavior was indeed the
nonexistence of an undefined XPath context in 1.0 implementations. 

--

Now, ehm, there is one more thing, sort of similar, that I find equally
confusing/annoying. Consider this pipeline:

<p:declare-step>
  <p:output port="result"/>

  <p:xslt>
    <p:input port="source">...</p:input>
    <p:input port="stylesheet">...</p:input>
    <p:with-param name="foo" select="...">...</p:with-param>
  </p:xslt>
</p:declare-step>

The example is invalid because the pipeline does not have a primary
parameter input port (and the "parameters" port of p:xslt is therefore
unconnected). Because of that, you have to do:

<p:declare-step>
  <p:output port="result"/>

  <p:xslt>
    <p:input port="source">...</p:input>
    <p:input port="stylesheet">...</p:input>
    <p:with-param name="foo" select="...">...</p:with-param>
    <p:input port="parameters">
      <p:empty/>
    </p:input>
  </p:xslt>
</p:declare-step>

My feeling is that just the presence of one or more p:with-param for a
parameter port should be enough. Typically, I think you want to say: I
want to pass params A and B to the step, and that's it. More rarely you
want: pass params A and B, and whatever else was passed to as parameters
to the owner pipeline.

What I am proposing is something like this:

If there is a p:with-param for a parameter input port, that port gets
*never* connected to the primary parameter input port of the owner
pipeline automatically; if you want that, you can always use an explicit
binding. If there is no p:with-param for a parameter port, the port gets
connected to the primary parameter input port of the owner pipeline.

I often find myself adding p:empty bindings to parameter input ports,
especially in pipelines that contain multiple steps that take
parameters. In virtually all cases, only one of these steps reads the
parameters from the owner pipeline; the other steps typically take the
parameters from somewhere else:

<p:xslt>...</p:xslt>
...
<p:xquery>...</p:xquery>
...

I guess I can live with the status quo (although I think it is a bit
confusing at times), but I would like to know what others think of such
a change.

Regards,
Vojtech

> -----Original Message-----
> From: public-xml-processing-model-comments-request@w3.org 
> [mailto:public-xml-processing-model-comments-request@w3.org] 
> On Behalf Of Norman Walsh
> Sent: Thursday, October 22, 2009 7:01 PM
> To: public-xml-processing-model-comments@w3.org
> Subject: Default binding for variable, option, parameter definitions
> 
> At the risk of being taken behind the woodshed and beaten to within an
> inch of my life by other members of the WG, since we are going back to
> Last Call anyway, I'd like the WG to consider one other change.
> 
> Aside from being a pointless way to set the path to "..", at present,
> the following pipeline is not valid:
> 
>   <p:declare-step>
>     <p:output port="result"/>
> 
>     <p:directory-list>
>       <p:with-option name="path" select="concat('.','.')"/>
>     </p:directory-list>
>   </p:declare-step>
> 
> It's not valid because there's no default readable port and there's
> no explicit XPath context established for the evaluation of the select
> expression. The most common way to make it valid is thus:
> 
>   <p:declare-step>
>     <p:output port="result"/>
> 
>     <p:directory-list>
>       <p:with-option name="path" select="concat('.','.')">
>         <p:empty>
>       </p:with-option>
>     </p:directory-list>
>   </p:declare-step>
> 
> In writing real-life pipelines, I've actually found this to be a
> significantly tedious problem. It seems clear to me that an
> alternative interpretation of the former pipeline would be to say that
> if there's no default readable port and no explicit binding, that the
> context is undefined and references to the context are an error.
> 
> I believe the WG discussed this and explicitly chose the current
> status quo. I can no longer recall (nor have I been able to find,
> though I admit I haven't looked very hard, record of) why we did this.
> 
> The only negative consequence I can see to this change is that an
> XPath 1.0 implementation has no way of representing an "undefined"
> context and so an XPath 1.0 implementation would fail to detect some
> errors.
> 
> If someone can remind me of some other negative consequence, I'd
> appreciate it.
> 
> I think, on balance, I would prefer to allow an XPath 1.0
> implementation to sometimes give the wrong answer rather than force
> every user to insert explicit empty bindings in what turn out in my
> experience to be a great many places.
> 
> I didn't consider this a significant enough irritation to warrant
> going back to Last Call to fix it, but if we have to go back to Last
> Call anyway, I propose that we change the rules so that if there's no
> default readable port and no explicit binding, the context is
> undefined and references to the context are an error.
> 
> I think the users will thank us.
> 
>                                         Be seeing you,
>                                           norm
> 
> -- 
> Norman Walsh <ndw@nwalsh.com> | I have animal magnetism. When I go
> http://nwalsh.com/            | outside, squirrels stick to 
> my clothes.
>

Received on Friday, 23 October 2009 08:56:46 UTC