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

[Bug 13494] Node uniqueness returned from XSLT function.

From: <bugzilla@jessica.w3.org>
Date: Tue, 09 Aug 2011 22:53:47 +0000
To: public-qt-comments@w3.org
Message-Id: <E1QqvBD-0000Yo-8H@jessica.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

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