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

[Bug 11821] [FT] Thesaurus option FTRange

From: <bugzilla@jessica.w3.org>
Date: Mon, 07 Feb 2011 20:11:42 +0000
To: public-qt-comments@w3.org
Message-Id: <E1PmXR0-0004Jf-0l@jessica.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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:45 UTC