On Tue, May 08, 2007 at 03:39:03PM +0200, Jan Flokstra wrote:

Hi Jens,

Hope you are still in Munich:-) We have a little problem here which we do not known how to debug. It is described extensively in the the e-mail at the end of this mail. But the basic problem is we do not know how to debug a typing problem. We have the following query:

tijah:query(fn:collection("c"),"//LINE[about(.,foul)]")

And the signatures of the function involved are:

(0) fn:collection (string) as node* (1) tijah:query(string) as node* (2) tijah:query(item*, string) as node* (3) tijah:query(string, item) as node* (4) tijah:query(item*, string, item) as node*

Yes, I am still here. First of all, the function signatures that you listed here are the ones that appear in the *comments* in xquery_fo.c. Unfortunately, the code says something different! Very dangerous! I have corrected this some minutes ago. So here's what happens during Core generation and type checking and why your example makes trouble. (It boils down to a conflict between the signatures (2) and (3).) Out of the possible implementations for a function (tijah:query()), Pathfinder's function scope checker assigns those to the function application that have the matching *number of parameters*. This is in the spirit of the W3C specs: user-defined functions may be overloaded, but must differ in the number of arguments (and not just be distinguishable by their types). Only built-in functions may be overloaded in the sense that two functions may have the same number of arguments, but different argument types. Then, Core generation in fs.brg looks at the required type for each of the arguments. If the function expects an atomic value, the function argument is *atomized* (i.e., nodes are converted into something atomic, typically xs:untypedAtomic). Pathfinder's type checker finally selects the most specific implementation if there is more than one for the given number of argument (only really relevant for built-ins). The problem that you are experiencing is a combination of the two foregoing paragraphs. The function scope checker assigns those function implementations with two arguments to the `apply' node (signatures (2) and (3)). Core generation then (randomly) picks on of these two to determine whether atomization is required. Type checking finally throws the error. This behavior is perfectly okay for all functions we had so far and for all functions in the W3C specs. The combination of (a) two function signatures with the same number of arguments and (b) arguments having a node type in one signature and an atomic type in the other is what bites you. You probably should rethink your two function signatures (2) and (3). Note that they also introduce some ambiguity. If I call the function as `tijah:query (node, node)', should the first or the second argument be casted to an atomic value? Note that this implicit atomization happens everywhere in XQuery (if necessary) and it is perfectly consistent to do this here as well. A clean solution would work without such two conflicting signatures. A hack could be to treat tijah:query() explicitly in the involved parts in the Pathfinder code and do something magic to make things work. I would not recommend to do so, though, as it primarily would introduce inconsistency. Don't hesitate to ask again if my answers weren't clear. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Please avoid sending me MS Word, MS Excel or MS PowerPoint files. Why? See http://www.fsf.org/philosophy/no-word-attachments.html