Saxon

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

I'd want to see a pretty good explanation of why you want to achieve this before making any changes designed to enable it. Although the XQuery spec does allow for prefixes to be declared externally, it seems a rather dubious practice to me. Perhaps if you explain your problem, rather than your proposed method of solving it, we'll find that there's a better approach. Michael Kay

Legacy ID: #3398379 Legacy Poster: Eric P. Wittmann (paalin)

Ok here goes. The context for this is that I've implemented support for XQuery as the expression language for BPEL. BPEL is an XML based language designed as an orchestration language for web services. The default expression language for BPEL is XPath 1.0, but that can be overridden for a given program. Typically expressions are used to either create or copy data from BPEL variables to other BPEL variables during the course of executing a BPEL "process" (program). The BPEL variables are typically either XSD types, custom schema types, or WSDL message types. In any of these cases, the variables are some sort of XML schema type. BPEL specifies various 'functions' that can be called in order to extract data from different parts of the process. For example, bpws:getVariableData() is a function that will extract data from a BPEL variable. An example of a BPEL expression written in XPath might be: concat( bpws:getVariableData('wsdlMessageName', 'wsdlPartName', '/path/to/node/in/complex/type'), '-old' ) This expression might evaluate to "filename.txt-old". In the case of XPath, since the only way to bind the bpws prefix to its namespace is programmatically, we supply our own INamespaceResolver to the XPath processor so that bpws is resolvable. For XQuery, the query itself could be written to include the namespace declarations, but that seems redundant since they are already mapped in the containing BPEL XML document. The additional wrinkle in our system is that we allow new FunctionContexts to be installed by users. Each FunctionContext has a namespace associated with it, so a function can be referenced/called from an expression language by its QName. Right now the BPEL process itself must have a prefix mapping to the custom function context namespace and then any function within that context can be called from an expression. The technical issue that I face is that the namespace resolver interface that I have access to has no way to enumerate the prefixes. As I see it I have the following choices: 1) Force BPEL authors to include namespace decls in their XQuery expressions (something they don't have to do in other supported expression languages) 2) Try to get the namespace resolver interface modified to add an enumerate facility (so I can programmatically add the mappings to the static query context)

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

OK, thanks for the explanation. I'll probably have similar issues when I get around to embedding XQuery in XSLT. I'll see what I can do. Michael Kay

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

I'm thinking in terms of adding the ability to nominate an external NamespaceResolver to StaticQueryContext as a "last resort" for resolving namespace prefixes. The only difficulty is those cases where prefixes need to be resolved at run-time rather than at compile time, specifically when dynamic element and attribute constructors evaluate the node name as a lexical QName containing a prefix. But perhaps one can simply handle that with a restriction, since you are wanting these prefixes only for lookup of function names. Michael Kay http://www.saxonica.com/

Legacy ID: #3437136 Legacy Poster: Eric P. Wittmann (paalin)

Apologies for taking so long to notice this reply. In the BPEL case, where the XQuery is essentially embedded within another XML document, an external NamespaceResolver is exactly what I was looking for. The namespace lookups will always be available at query compile time, since they are mapped in the containing document (at least for MY case). So your suggestion sounds like it's just what I need.