Hi,
I'm getting an error using chained xquery modules in saxona 8.1.1 (8.2 with JAXP 1.3 is not an option). If I have the following setup:
main.xquery:
import module namespace ns1 = "http://xxx/module1" at "module1.xquery";
ns1:test-module-1()
module1.xquery:
module namespace ns1 = "http://xxx/module1";
import module namespace ns2 = "http://xxx/module2" at "module2.xquery";
declare function ns1:test-module-1()
{
ns2:test-module-2()
};
module2.xquery:
module namespace ns2 = "http://xxx/module2";
declare function ns2:test-module-2()
{
<OK/>
};
Then I get the following error on executing main.xquery:
Error
XQuery syntax error on line 1 of file:/Users/antony/Desktop/SaxonTest/main.xquery in ...1" at "module1.xquery"; import:
Function ns2:test-module-2 has not been declared
Declaring ns2 in main.xquery makes no difference (as you would expect).
Is this a known bug? Any clues? I'm doing a translation from xslt, and flattening my modules would be anti-modulatisation/reuse nightmare.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've reproduced the error on Saxon 8.1.1 and can confirm that it's gone away on Saxon 8.2. I can't identify any specific known bug that would cause this. I'm afraid I'm not set up to do detailed debugging on the 8.1.1 code base. I'm working to try and reduce the problems that the JAXP 1.3 situation has caused - it's not easy to produce DOM-based software that works smoothly on both JDK 1.4 and JDK 1.5.
Michael Kay
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should further add that the license for JAXP 1.3 doesn't allow it to be redistributed, and hence saxon 8.2. can't be used on 1.4 in a commercial setting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, 8.1.1 won't allow a module with a namespace to import anything from any other module. The top level module works because it doesn't have a namespace. The error is that QueryParser.parseModuleImport tries to import functions by calling StaticQueryContext.declareFunction() on the importing module, but that function is used for DECLARING functions, and hence barfs because the namespace of the imported function doesn't match.
The problem is hidden because even though that function throws a StaticError, it is swallowed by QueryParser.parseProlog by the skip-forward error recovery.
It's simple to fix - add importFunction/Variable parallels to declareFunction/Variable that don't check the namespace, but I'm going to download 8.2 to look at the source to find what's changed to fix it there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In 8.2 StaticQueryContext.declareFunction() doesn't check that the namespace matches the module namespace. Rather it checks that the user isn't overriding an atomic type constructor. Hence the original problem doesn't occur.
In both 8.2 and 8.1.1, QueryProcessor.parseFunctionDeclaration checks that the declared function is in the same namespace as the module, so the check in 8.1.1 StaticQueryContext.declareFunction() is redundant and can be removed - problem solved!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry I've been letting you conduct a monologue on this. SourceForge has stopped notifying me of posts to the forum, so I've been relying on taking a look once a day, and I tend only to spot new threads and not additions to previous threads. Using the mailing list is more reliable.
I understand the licensing problems and hope to come up with a solution soon.
I think your reasoning is correct, and reflects the logic I used when making the changes in 8.2.
Michael Kay
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm getting an error using chained xquery modules in saxona 8.1.1 (8.2 with JAXP 1.3 is not an option). If I have the following setup:
main.xquery:
import module namespace ns1 = "http://xxx/module1" at "module1.xquery";
ns1:test-module-1()
module1.xquery:
module namespace ns1 = "http://xxx/module1";
import module namespace ns2 = "http://xxx/module2" at "module2.xquery";
declare function ns1:test-module-1()
{
ns2:test-module-2()
};
module2.xquery:
module namespace ns2 = "http://xxx/module2";
declare function ns2:test-module-2()
{
<OK/>
};
Then I get the following error on executing main.xquery:
Error
XQuery syntax error on line 1 of file:/Users/antony/Desktop/SaxonTest/main.xquery in
...1" at "module1.xquery"; import
:Function ns2:test-module-2 has not been declared
Declaring ns2 in main.xquery makes no difference (as you would expect).
Is this a known bug? Any clues? I'm doing a translation from xslt, and flattening my modules would be anti-modulatisation/reuse nightmare.
I've reproduced the error on Saxon 8.1.1 and can confirm that it's gone away on Saxon 8.2. I can't identify any specific known bug that would cause this. I'm afraid I'm not set up to do detailed debugging on the 8.1.1 code base. I'm working to try and reduce the problems that the JAXP 1.3 situation has caused - it's not easy to produce DOM-based software that works smoothly on both JDK 1.4 and JDK 1.5.
Michael Kay
Michael,
This is in a WebStart app targeting OS/X, so neither 1.5 nor endorsed dirs are an option for me.
Could you give me a quick pointer to where in the code I should start? I'll try to fix this.
Thanks
I should further add that the license for JAXP 1.3 doesn't allow it to be redistributed, and hence saxon 8.2. can't be used on 1.4 in a commercial setting.
OK, I've found the bug(s):
First, 8.1.1 won't allow a module with a namespace to import anything from any other module. The top level module works because it doesn't have a namespace. The error is that QueryParser.parseModuleImport tries to import functions by calling StaticQueryContext.declareFunction() on the importing module, but that function is used for DECLARING functions, and hence barfs because the namespace of the imported function doesn't match.
The problem is hidden because even though that function throws a StaticError, it is swallowed by QueryParser.parseProlog by the skip-forward error recovery.
It's simple to fix - add importFunction/Variable parallels to declareFunction/Variable that don't check the namespace, but I'm going to download 8.2 to look at the source to find what's changed to fix it there.
Solved!
In 8.2 StaticQueryContext.declareFunction() doesn't check that the namespace matches the module namespace. Rather it checks that the user isn't overriding an atomic type constructor. Hence the original problem doesn't occur.
In both 8.2 and 8.1.1, QueryProcessor.parseFunctionDeclaration checks that the declared function is in the same namespace as the module, so the check in 8.1.1 StaticQueryContext.declareFunction() is redundant and can be removed - problem solved!
Sorry I've been letting you conduct a monologue on this. SourceForge has stopped notifying me of posts to the forum, so I've been relying on taking a look once a day, and I tend only to spot new threads and not additions to previous threads. Using the mailing list is more reliable.
I understand the licensing problems and hope to come up with a solution soon.
I think your reasoning is correct, and reflects the logic I used when making the changes in 8.2.
Michael Kay