W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2015

[Bug 4378] error in K2-NodeTest-21

From: <bugzilla@jessica.w3.org>
Date: Wed, 11 Nov 2015 04:03:34 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-4378-523-yrVoPBdTEl@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=4378

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #30 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
There's another implementation issue that perhaps should be looked into when
considering requiring a static error when a context item is referenced:

<xsl:function name="f:run">
    <xsl:param name="fun" />
    <xsl:value-of select="$fun()" />
</xsl:function>

<xsl:template match="/">
    <xsl:value-of select="f:run(node-name#0)" />
    <xsl:value-of select="f:run(position#0)" />
    <xsl:value-of select="f:run(function-lookup('node-name', 0))" />
</xsl:template>

We apply function rewriting and inlining in this case *after* the static
analysis phase. During static analysis, we do not detect this as an error case.
The rewrites result in the whole body being replaced with a single call to some
version of fn:error('xyz').

If the context item should be statically detected as being absent, I don't
think that is trivial in the above example, though possible because all calls
are static. But even if you do see this as an error case, it should still be
dynamic because we cannot know beforehand whether the template is matched.

1) in the above example I think it should clearly be a dynamic error, even
though proposals below suggests this should be statically detected.

2) the inlining removes the knowledge of being inside a function, the inlining
happens after the static error checking phase. We currently apply the same
strategy for other places where the context item can be absent and treat them
all as dynamic errors. Turning this around is not trivial, I think (but by no
means impossible).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 11 November 2015 04:03:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 November 2015 04:03:39 UTC