- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 01 Dec 2005 22:27:55 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2553 ------- Additional Comments From davidc@nag.co.uk 2005-12-01 22:27 ------- similar comments would apply to doc() and xslt's document() functions Consider (to take a real example) processing the set of XqueryX files in the xquery test suite (as input documents, to do some kind of transformation, or query-on-queries. The files are (typically) on the filestore so Michael's comments about the non-availablility if database-style locking mechanisms applies, but you wouldn't normally want to load them via collection, but rather something like <xsl:for-each select="descendant::qt:test-case"> ... select="doc(concat(@FilePath,query/@name,'.xqx'))" ... If you try doing this on a system that holds all documents in memory you run out of memory pretty quickly (or have a much bigger machine than I have) Saxon's discard-documemnt extension function has proved invaluable in making this type of operation, processing large numbers of smallish files, feasible. Something in the standard that addresses this (it doesn't have to be exactly discard-document) would be really useful, I think, otherwise I suspect that discard-document is going to be 2.0's xx:node-set() ie a must-have extension that every implementer has to implement, and which causes confusion to beginners who don't know why they need an extension anyway, and causes interoperability problems for non-beginners (due to usual extension function issues about differences of behaviour in edge cases, different namespaces, etc) I know it's late in the process, but CR is about implementation experience, and a worryingly large proportion of my xslt2 stylesheets are using this extension, already. David
Received on Thursday, 1 December 2005 22:27:58 UTC