- From: Michael Rys <mrys@microsoft.com>
- Date: Mon, 16 Feb 2004 18:49:20 -0800
- To: "Stephen Buxton" <Stephen.Buxton@oracle.com>, <public-qt-comments@w3.org>
I think the best solution is to remove this function from the specification. I for example don't see fn:collection() to be useful if it is not stable and would consider any implementation that does not guarantee some internal caching/concurrency control system to not be fit to support fn:collection(). Since I assume that there will be many such implementations, I think we better remove the function instead of adding even more (and thus more complexity)... Best regards Michael > -----Original Message----- > From: public-qt-comments-request@w3.org [mailto:public-qt-comments- > request@w3.org] On Behalf Of Stephen Buxton > Sent: Monday, February 16, 2004 6:47 AM > To: public-qt-comments@w3.org > Subject: ORA-FO-186-C: fn:collection stability requirements > > > SECTION 15.4.5: fn:collection > > It says that this function is stable, meaning that two invocations > during the same expression evaluation have the same result. > Since the size of the result of an fn:collection evaluation may > be very large, it will not be practical for XQuery to take a > snapshot and guarantee stability that way, and consequently > fn:collection must rely on resolving the URI on demand. > This means that the stability requirement is unreasonable in many > environments: > > a) if fn:collection is evaluated by resolving to a resource that > is outside the transaction management of XQuery, then the > values at that resource might change dynamically, and not just > at times between evaluations of XQuery expressions. > > b) if fn:collection is evaluated by resolving to a resource such > as a relational database, which does not assure a stable ordering > of results. > > Perhaps the solution is to provide fn:stable-collection > and fn:unstable-collection. fn:stable-collection would > return an error if it is not possible to assure stability. > Let the user indicate whether he really needs stability. > > - Steve B.
Received on Monday, 16 February 2004 21:49:05 UTC