[basex-talk] Counterintuitive behavior with cast to double

Hi, I'm Shuxin. Recently I came across this test case in which BaseX returned counterintuitive result. From my feelings it seems like a bug but the behavior of Saxon is similar, and therefore is hard for me to confirm. Give XML document 111 and XPath query //*[boolean(.) cast as xs:double] Bo

[basex-talk] Empty namespace declarations

Hi, we've recently updated BaseX from 10.5 to 10.6 and it seems there was some change in the namespace declaration behavior. Example: declare function local:list() as element()+ {   (     1,     2,     3   ) }; declare function local:to-json() as element() {     http://www.w3.org/2005/xpath-

Re: [basex-talk] Counterintuitive behavior with cast to double

On 5/23/2023 11:35 AM, Shuxin Li wrote: Hi, I'm Shuxin. Recently I came across this test case in which BaseX returned counterintuitive result. From my feelings it seems like a bug but the behavior of Saxon is similar, and therefore is hard for me to confirm. Give XML document 111 and XPath q

Re: [basex-talk] Counterintuitive behavior with cast to double

Dear Shuxin, > Both Saxon and BaseX return the result node set [1, 2]. However, the nodes > with id 2 and 3 seems identical to me and is hard to understand why node 2 is > selected while 3 is not. If node 2 is deleted from the XML document, result > set [1,3] is returned. I'm interested in whet

Re: [basex-talk] Empty namespace declarations

Hi Johannes, This was a known bug in the previous version, the new behavior is correct: The elements in the user-defined function have no namespace, and by inserting them as child nodes, the namespace must not be changed. Things work differently if the node constructors are defined within the cu