W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > October 2009

Re: Default binding for variable, option, parameter definitions

From: Florent Georges <fgeorges@fgeorges.org>
Date: Thu, 22 Oct 2009 20:04:32 +0200
Message-ID: <ebaca5bf0910221104t3274678bg14a65fe55aa9e63@mail.gmail.com>
To: Norman Walsh <ndw@nwalsh.com>, public-xml-processing-model-comments@w3.org
Hi,

I agree. Furthermore, this is consistent with function definitions in
both XSLT 2.0 and XQuery.

Regards,


On 10/22/09, 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.
>

-- 
Sent from my mobile device

Florent Georges
http://www.fgeorges.org/
Received on Thursday, 22 October 2009 18:06:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:27 UTC