W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2011

[Bug 13747] [XPath 3.0] Determinism of expressions returning constructed nodes

From: <bugzilla@jessica.w3.org>
Date: Wed, 10 Aug 2011 14:36:27 +0000
To: public-qt-comments@w3.org
Message-Id: <E1Qr9tT-0006Rc-Oq@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13747

Vladimir Nesterovsky <vladimir@nesterovsky-bros.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vladimir@nesterovsky-bros.c
                   |                            |om

--- Comment #1 from Vladimir Nesterovsky <vladimir@nesterovsky-bros.com> 2011-08-10 14:36:26 UTC ---
(In reply to comment #0)

> I'd like to suggest the possibility of abandoning the rule (that multiple
> evaluations must return distinct nodes) entirely.

1. This can have consequences that go beyond of "loop-lifting and
common-subexpression-refactoring".

The code like the following may potentially become undefined:

<!-- 
  repeatable big subtree can be respresented by optimizer,
  as a hidden function call: $impl$:subtree(). 
-->
<xsl:variable name="a">
  <a/> 
</xsl:variable>
<xsl:variable name="b">
  <a/>
</xsl:variable>

<xsl:sequence select="$a is $b"/>

As implementation might (or might not) refactor it the way that $a is the same
node as $b.

2. Xslt spec already specifies which instruction produce new nodes, so there is
no ambiguity present in each particular case.

3. Engine is allowed to optimize the code but not to violate rules defined by
spec (see 2)

4. If engine is not certain if it's possible to perform an optimization then it
should not do it. This addresses dynamic calls that cannot be verified
statically.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 10 August 2011 14:36:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:36 UTC