XQXQ should set base URI of execution context

This information is not available for the module since the base URI present when the module takes action is the base URI of the module "http://www.zorba-xquery.com/modules/xqxq"

What I could do is add a parameter to set a base URI, or probably there could be a way to patch zorba to send the correct base URI to the module but that would be an ugly an invasive solution.

I made a rough implementation of how to solve this, though is rally invasive and don't know if there is an other way of getting the main query base URI into the module.

I agree, the proposed solution is fairly invasive and hacky, although it does get the job done.

Now that we are at Zorba 3.0, however, we have a better solution: add additional (optional) arguments to ContextualExternalFunction::evaluate() so we can pass the Static and Dynamic Contexts of the *caller* to external functions. eg:

class ZORBA_DLL_PUBLIC ContextualExternalFunction : public ExternalFunction
{
  virtual ItemSequence_t
  evaluate(
      const Arguments_t&,
      const StaticContext* aModuleSctx,
      const DynamicContext* aModuleDctx,
      const StaticContext* aCallingSctx,
      const DynamicContext* aCallingDctx) const = 0;

The only slightly ugly bit is that this is a virtual function, intended to be overridden by user-provided subclasses. We have two choices:

1. Provide just the above signature. This would force every user-created ContextualExternalFunction implementation to be re-written to match the new signature.

2. Continue providing the old signature as well as the new one. Users could override either one depending on their needs. In that case, we would need to provide a stub implementation of the original signature that returned some sentinel value (and make that method non-pure virtual). The implementation of FnCallIterator would call the first, see if the return value matched the sentinel, and if so call the second.

I prefer solution (2) *if* it doesn't imply a significant performance overhead.

This is orthogonal to the discussion because it relates to FOTS driver and FOTS the main consumers of XQXQ.

As far as W3C is concerned, they agreed that some test-cases assume that the base-uri is assumed to be set to the file that contains the test-case (typically this is the test-set).

They addressed the issue in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22279

As a result I have opened lp:1187807.

Until XQXQ will provide a nice way of exposing the static and dynamic contextes, I will update FOTS driver to add in the prolog of the test-case the setting of base-uri.

My original idea was to pass through the base URI of the query invoking ZQ. However, even that wouldn't have helped FOTS driver as it happens. So, it seems that nobody really needs this fix after all.

Juan proposed a change which at least causes the base URI to be something valid, namely the ZQ module URI. I'm merging that and claiming this bug is fixed.