- From: Jim Tivy <jimt@bluestream.com>
- Date: Sun, 18 Apr 2004 13:20:16 -0700
- To: "Jason Hunter" <jhunter@acm.org>
- Cc: "Michael Rys" <mrys@microsoft.com>, "Howard Katz" <howardk@fatdog.com>, <www-ql@w3.org>
Jason I would use the external environment to bind my variable to a collection. My external environment which is an XML database knows about collections independent of XQuery. So I expose an API call like XPreparedStatement prepStmt = prepareStatement("$input"); // this is type checked against the type of $input prepStmt.bindExternalVarToCollection($input,"MyDb:staged"); then call XResultSet results = prepStmt.execute(); All of the above is all "outside" the XQuery Language and its specification in the "external environment". Note in the Nov XQueryLanguage Spec 4.8 If the variable declaration includes the keyword external, a value must be provided for the variable by the external environment before the query can be evaluated. If the value provided by the external environment is not compatible with the declared type of the variable, a type error is raised. If I want to query across all foo elements and don't want to make a query $input/foo, then I have the following query. declare variable $input as ... external declare variable $foo as ... $input/foo $foo [38] VarDecl ::= "declare" "variable" "$" VarName TypeDeclaration? (("{" Expr "}") | "external") You could probably do this using a function along the lines of: declare variable $input as ... external foo($in as item*) returns element foo { $in/foo } foo($input) cheers Jim > -----Original Message----- > From: www-ql-request@w3.org [mailto:www-ql-request@w3.org]On Behalf Of > Jason Hunter > Sent: Sunday, April 18, 2004 12:20 PM > To: Jim Tivy > Cc: Michael Rys; Howard Katz; www-ql@w3.org > Subject: Re: top-level location-path context dependencies > > > > But Jim, I'd like to know exactly how you get your $input or $production > variables bound in your query. Let's assume your use case is you want > to query for all foo elements across all documents in your document > store. So how do you set up $input? > > There's no mechanism in XQuery to see all the documents, so you can't > use XQuery to set up the binding. > > In a Java interface like XQJ you have no visibility into what's already > in the XQuery engine, so you can't use Java to set up the binding. > > Seems to me you're stalled before you even begin! > > -jh- > > Jim Tivy wrote: > > > Folks > > > > I think we need use cases to discuss. > > > > What is your use case? > > > > Let me imagine a use case...: > > > > For a use case where you have two collections - "production" > and "staged". > > I have an application which I want to run against either production or > > staged. The application has queries. I would want to have a variable > > called $input which I use in the queries and which I could set > as part of > > the context to production or staged. > > > > Now if I have two collections in each environment - prodNews > and stagedNews > > and prodWhitepaper and stagedWhitepaper, then I might want to have two > > variables $news and $whitepaper which I use in my application > and which I > > set in the query context according to whether I am going against the > > production or staged collections. > > > > In this case having input() is not much use, but having variables is. > > > > Standardizing on default collections for the purpose of > interoperability may > > not be a useful pursuit of a standard. Having a mechanism that allows a > > query to work off its context is probably a useful pursuit of a > standard. > > > > cheers > > Jim > > > > > >>-----Original Message----- > >>From: www-ql-request@w3.org [mailto:www-ql-request@w3.org]On Behalf Of > >>Jason Hunter > >>Sent: Sunday, April 18, 2004 11:20 AM > >>To: Michael Rys > >>Cc: Howard Katz; www-ql@w3.org > >>Subject: Re: top-level location-path context dependencies > >> > >> > >> > >>Michael Rys wrote: > >> > >> > >>>In XQuery, the solution is very simple if you make it explicit: > >>> > >>>Bind a variable to the sequence. > >> > >>The other solution is to bring back input() from the May 2003 draft. > >>That's actually more elegant. > >> > >>-jh- > >> > >> > > > > > >
Received on Sunday, 18 April 2004 16:21:35 UTC