[xquery-talk] Setting global variables

[Hans-Juergen Rennau]

You wrote:

> Currently, I pass such information from function to function until it
 is 
> finally used. While this works (and some would argue is the correct 
> style), it has the following drawbacks:
> 
> 1) It is difficult to follow the information through the chain of 
> functions.
> 
> 2) It can be confusing to read the intermediate functions, as these 
> never really use the information.
> 
> 3) It is brittle when refactoring the intermediate functions. Because
 
> the information is not really used -- it's just passed along -- it is
 
> easy to accidentally drop.

Hello Ron,

the issue you raised seems to me very important in the context of library design. I vividly share your unease about passing around information everywhere only because here and there some piece is needed. However, in a library module this is the only approach to let input dependence be a dependence on call parameters, rather than on external variables. If a library module offers but one "public" function, my practice is to let that function start by building a "control" structure ($c) which integrates everything that might be required anywhere in the module, and then indeed let any other signature begin with that control parameter. The harm done to the signatures is at least uniform and short ($c as element(my:control)).

This approach becomes problematic if the module offers more than one "public" functions. A couple of remarks on the alternative approach of using input-dependent global variables. As has been clarified, the input-dependence means that either the variable itself is external, or its assignment expression references an external variable. This is a very grave matter for a library module: any module (main or library) using this module can only do so in the context of a query invocaton which passes that external parameter! The constraint is acceptable if the library module is to be used only in the context of a specific query, but hardly so if the library module is intended to be reusable software. If more than one input-dependent library module gets involved, things get very brittle, and obscure. 

One approach to alleviate the matter is a design pattern to be observed across all (!) library modules of a system. The basic idea is that any query whose evaluation leads "into" your set of library modules passes - beside any others - *one* external parameter with a fixed name, say {example.com/env}env, which is either a document or element node, or the URI of an XML document. The parameter is "caught" by a dedicated module containing the matching global parameter, and in a normalized way (e.g. by exposing the document element) made accessible to any module in need of input-dependent global variables. The 'env' document obviously serves as a container for any information required by input-dependent modules.  Any such module knows the path(s) of any input information it requires, and accesses it in the assignment expression of its own global variables. The documentation of such a library module contains a table where one column specifies a path within
 'env', and the other column the semantics of the fragment thus defined. This approach also allows to define default values, which are used when the respective path finds nothing. (In the extreme case, the invocation passes simply an empty 'env' element, or a zero-length string!) Designing a query making use of input-dependent library modules, the query author documents the implied dependence on external parameters by simply concatenating the library module specific dependency tables. On the other end of the system - where the query is invoked - the concatenated table serves as a plan according to which 'env' is constructed.  

Using namespaces, the 'env' can integrate completely diverse information required by completely unrelated modules (e.g. modules dedicated to SQL access and other ones offering SOAP connectivity). 

On first sight, this approach seems complicated, but once one accepts the overall convention that any query does provide an 'env' parameter, the contents of which are composed in a query-dependent way, the final result is simply an API of sorts, what concerns the invocation side, and a uniform pattern of environment access, what concerns the implementation side. 

With kind regards -
Hans-Juergen Rennau





      Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: 
http://de.yahoo.com/set