- From: <bugzilla@jessica.w3.org>
- Date: Tue, 09 Aug 2011 22:53:47 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13494 --- Comment #1 from Michael Kay <mike@saxonica.com> 2011-08-09 22:53:45 UTC --- This question is a difficult one. The fact that two calls on a function can (or must?) deliver two nodes with distinct identity is a feature that very few applications are likely to depend on, and yet it greatly complicates the language semantics, and places considerable constraints on an optimizer. In fact the rules have never been very clearly stated in XSLT; there has been more of an attempt in XQuery. The existence of the generate-id() function, whose result explicitly depends on node identity, exacerbates the problem. (Saxon does attempt to ensure that repeated calls on a function that creates new nodes create different nodes each time, and cannot therefore (for example) be moved out of a loop. It also makes some attempts to recognize dependencies on generate-id(). But in the end, recognizing such dependencies N levels deep becomes increasingly difficult, and arguably impossible when dynamic invocation is taken into account.) I think there is a good case for going the other way, and making it explicitly implementation-dependent whether two calls on a function with the same arguments construct the same node or different nodes. I find it hard to believe that many applications would be affected by this. The application in this case is deliberately trying to take advantage of the node-identity peculiarity in order to produce a function that delivers different results each time it is called. Perhaps we should really be looking at this as an application requirement and considering how it should be addressed, rather than trying to define more predictable semantics for functions that depend on node identity? Perhaps we should look at how other functional languages tackle this problem. (Personal response) -- 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 Tuesday, 9 August 2011 22:53:52 UTC