Tim,
Thanks for your response. Unfortunately, the work-around you suggest doesn't seem to work for me. I had populated the target collection with multiple schemas, some declaring a default namespace and some mapping it to a prefix. The only nodes returned were from those schemas that bound the "http://www.w3.org/2001/XMLSchema"; namespace to a prefix.
The unbound XPath expression (/schema/[EMAIL PROTECTED]'FooType']) never yielded any results, despite the namespace mappings set for the query service. The bound expression (/xsd:schema/xsd:complexType[ @name='FooType']) never retrieved nodes from schemas employing a default namespace assignment.
-richard
At 04:11 PM 2/8/2002 -0600, you wrote:
I tried to track this bug down a while ago: It appeared to me at the time that there was a problem within the Xalan implementation which is used for XPath evaluation. When I stepped through the SAX events that occur when parsing the query string, it did not appear that the prefix resolver was being invoked when the query path had an unqualified (i.e. default) element or attribute. I was never able to find the time to dig any deeper.
The good news is that you can work around the problem pretty easily. Even if your schema document is stored using a default namespace (as shown in your second example), you can perform the query using a non-default query. So, you should be able to store your document as in Example 2. When you want to perform your query, you can use the query syntax from your first example. As long as you've set the namespace on your service as you've specified:
service.setNamespace( "xsd", "http://www.w3.org/2001/XMLSchema"; );
Then everything should work with the query "/xsd:schema/xsd:[EMAIL PROTECTED]'FooType']". It does not matter if the "xsd" prefix is not used in the document that is stored.
I still plan to look into this bug if I get a chance, but my schedule's been pretty tight lately.
Hope that helps!
- Tim
