Re: Default binding for variable, option, parameter definitions

Speaking as a user, I would thank you for this.  I get tripped up on
this more frequently than I'd like to admit, and I know better by now.
 It's really confusing to new users.

The only other major item on my wish list is support for attribute
value templates in step options, which would go a long way towards
reducing the verbosity of XProc.  But given the late date, I'm not
suggesting that the WG actively consider such a major change.  Just
throwing out there why we're on the subject.  There's always v2.

Thanks,

-James



On Thu, Oct 22, 2009 at 12:00 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> 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 Thursday, 22 October 2009 17:30:40 UTC