- From: <bugzilla@jessica.w3.org>
- Date: Mon, 07 Feb 2011 20:11:42 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11821 --- Comment #6 from Paul J. Lucas <paul@lucasmail.org> 2011-02-07 20:11:41 UTC --- OK, I'll bite: why can't the operands of other match options be dynamic as well? I suggest that in a large number of uses for XQuery, it won't be the the only programming language used in some larger application. For example, if I have some web service that offers a thesaurus API to the world, the entire application is not written in XQuery, i.e., the web server isn't written in XQuery. Instead, the web server (written in C or Java) will accept a request with parameters and ultimately call some function written in XQuery. Said function will nee to be parameterized. Why then can't (for example) all URILiterals, instead of being literals, be allowed to be dynamic? declare variable $thesaurus-uri as xs:string external; (: ... :) $doc contains text $query using thesaurus at $thesaurus-uri To achieve such functionality now, developers are going to do ugly hack substitution things like: (: ... :) $doc contains text $query using thesaurus at %%tTHESAURUS_URI%% then do substitutions on the source code, compile the XQuery on the fly, then execute it. If what are currently all URILiterals were allowed to be dynamic, such queries could be pre-compiled or "prepared" just like SQL statements can be prepared by using '?'. -- 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 Monday, 7 February 2011 20:11:44 UTC