Saxon

Legacy ID: #2804714 Legacy Poster: Michael Kay (mhkay)

There are a few things here I need to look at, especially (a) why isn't the type of the variable recognized at the time the function binding happens, and (b) why the secondary errors after the primary error is reported. Generally, calling polymorphic Java methods is not always possible, though Saxon does its best to make a decision based on the static type information available. For both these examples, there are two candidate constructors in the Java class. For the second example, I would have expected the ambiguity to be resolved by writing: declare namespace file="java:java.io.File"; declare namespace j="http://saxon.sf.net/java-type"; file:new(file:new("prefix") treat as j:java.io.File, "suffix") but it doesn't seem to work - I'm not sure why. I suspect the function binding algorithm is ignoring extension types. Note that the -TJ option on the command line gives a lot of extra information about what is going on. Michael Kay

Legacy ID: #2804728 Legacy Poster: Michael Kay (mhkay)

Just another observation, which is that the change between Saxon 8.0 and 8.1 here is not a great surprise. Until Saxon 8.0 binding of external functions was done dynamically based on the dynamic types. I decided that this was too dependent on the weak typing approach of XPath 1.0 and that a more strongly/statically typed mechanism was needed, one that was more closely aligned to the XPath 2.0 function calling rules. This means that polymorphic methods can only be bound if the static types of the arguments are known in sufficent detail. In general this means using "treat as" to give extra type information to the compiler. Michael Kay

Legacy ID: #2807485 Legacy Poster: Heinrich Rust (hrust)

Thanks a lot for your quick and precise answers! I am already using the helpful -TJ option to understand the resolution of external function calls. I like that you switched to a stricter typing scheme for external function calls, and I am glad to learn that there is a namespace which should enable me to give the XQuery interpreter the information it needs for resolving ambiguities normally. Is there a way to get around the problem for now (other than switching back to saxonb8-0)? Sincerely - Heinrich Rust

Legacy ID: #2808207 Legacy Poster: Michael Kay (mhkay)

I have now fixed these problems in the source code, but the changes are rather too extensive to supply as a patch, so I regret they will have to wait until the next release. Specifically, where a function call matches more than one Java method, the binding to a specific method is now delayed until static type analysis has been performed on the expression tree, which means it has a better chance of disambiguating the call (it will still be necessary in some cases to use a cast or "treat as" to supply the type information needed). Also, "extension types" (types that map to Java classes) are now analysed properly by the binding algorithm,when they appear as arguments of an extension function call. Michael Kay