xqxq: add new bind-variable signature

[Sorin Marian Nasoi]

I would need the following signature added to XQXQ:

declare %an:sequential function xqxq:bind-variable(
  $query-key as xs:anyURI,
  $var as xs:QName,
  $value as xs:string*) as empty-sequence() external ;

such that the XQXQ can cast to the correct type internally.

details about the issues I have:
- one creates a XQUERY (please see below) that raises an error because of the external variable binding:
xqxq:bind-variable( $queryID, xs:QName("ext"), "5");
should be
xqxq:bind-variable( $queryID, xs:QName("ext"), xs:integer(5));

XQUERY:

import module namespace xqxq = 'http://www.zorba-xquery.com/modules/xqxq';
variable $queryID := xqxq:prepare-main-module('xquery version ''3.0'';

declare variable $ext as xs:integer external := 0; <a>{$ext}</a>');
xqxq:bind-variable( $queryID, xs:QName("ext"), "5");
xqxq:evaluate($queryID)

[Juan Zacarias (juan457)]

Sorin I don't understand why you need the new signature with xs:string* since the current signatures should cover strings too, since the current signature is

declare %an:sequential function xqxq:bind-variable(
  $query-key as xs:anyURI,
  $var as xs:QName,
  $value as item()*) as empty-sequence() external ;

And sorry don't understand the problem, The query you attached is breaking because you are trying to attach a xs:string to a xs:integer variable.

declare variable $ext as xs:integer external := 0;
                                            ^
 In my eyes this is a correct error, but I don't know much xquery, is zorba supposed to do an automatic cast of the string to an integer?

                                                  ^

[Sorin Marian Nasoi (sorin.marian.nasoi)]

The current functionality is working but it assumes that the user knows before hand the type of the variable it wants to bind the value to.

I asked how hard would be to add a new signature that does not receive the type of the value, just the value.
If there is a type defined in the external variable, XQXQ should try to cast the passed value to that type.
If it does not succeed than raise an error.

Does it make sense?

One reason is that there are several tests in FOTS that declare an external variable with a type
[...]
declare variable $ext as xs:integer external := 0;
[...]

And then you are suppose to bind a value "2" given as string to that variable.

These types of test cases check if the binding of the variable is done after the variable declaration.
Meaning if in the end the value of the $ext is xs:integer(2).

[Sorin Marian Nasoi (sorin.marian.nasoi)]

Think of it like this:

if the user already mentioned that the type of the external variable is let's say xs:integer :

Query:
[...]
declare variable $ext as xs:integer external := 0;
[...]

And then it needs to bind the value 2, why can't he use a function signature where the passed value is automatically casted to the needed type? Why does XQXQ needs the user to mention again the type of the variable?

I mean if that is not hard to do, it would help the user, don't you think?

[Sorin Marian Nasoi (sorin.marian.nasoi)]

Given the query:
[...]
declare variable $ext as xs:integer external := 0;
[...]

for
xqxq:bind-variable( $queryID, xs:QName("ext"), "5");
I'm guessing that in XQXQ, at this moment you do something like this:
- if the passed type is the same as the type of the variable => bind the value; Otherwise raise an error.

The new functionality I was mentioning would do something like this:
If the type of the given value (xs:string in this case) can be casted to the type of the variable (xs:integer) then cast the value and bind it to the variable. Otherwise raise an error.

[Juan Zacarias (juan457)]

Ok, I think I understand what you were requesting now.

But instead of changing the signature of the function, it may be better to try to cast the variable to the new format instead of writing a new signature.

Since if I add the xs:string* signature and keep the item() signature when a string is used it won't know what signature to use, and if I remove the item()* signature I will destroy some of the native behavior of the bind variable and will have to always do cast types to all entries which are not strings. which will be just causing overhead to the function.

So I will make some changes to make something like this work at least for the xs:string now without having to modify the signature of the function.

[Sorin Marian Nasoi (sorin.marian.nasoi)]

Great, it seems to me you got what I meant/needed even though I did not express it right :)
Thanks for the help Juan.

[Juan Zacarias (juan457)]

Hi Sorin,

There are some complications with your request than I couldn't though off until now, there is no way without changing the zorba API of knowing what type was specified for the external variable in the query until the evaluate function. And in the evaluate function it is to late for recasting the function.

I am going to try to modify the Zorba API to add this functionality, but either way I am not sure if it will work. I will keep poking around to see if I can actually do this.

[Juan Zacarias (juan457)]

Hi Sorin I have a solution for this problem.

Let me know if this fulfills your needs.

[Sorin Marian Nasoi (sorin.marian.nasoi)]

I can not find the original test case any more.
I also double checked and there are no FOTS failures caused by this issue: have to remove the "fots" TAG.

Let's assume this test-case:

   <test-case name="example">
      <environment>
         <param name="ext" select="5" declared="true"/>
      </environment>
      <test>declare variable $ext as xs:integer external := 0; $ext</test>
      <result>
         <assert-type>xs:integer</assert-type>
      </result>
   </test-case>

Here, the FOTS driver does not "know" the type of the variable (without scanning the test off course) so
all the FOTS driver can do is bind the variable as
xqxq:bind-variable( $queryID, xs:QName("ext"), "5");

But this will fail because the correct declaration (in the current XQXQ version) should be:
xqxq:bind-variable( $queryID, xs:QName("ext"), xs:integer(5));

HTH.