[xquery-talk] xquery library design

Jakob Fix jakob.fix at gmail.com
Tue Dec 27 15:13:08 PST 2011


Hello,

I'm about to write an xquery library and I'm curious whether there are
best practices around regarding the inclusion of other library modules
(a quick Google search didn't turn up anything useful).

In particular, I'm interested in how one would implement this:

- a library module (out of several)
  that uses configuration data specific for each application it is used in, and
  that itself makes use of lower-level functions.

for example, a library module with a number of publicly exposed api
functions that each would take an "api_key" argument that is specific
to the application and probably stored in a separated configuration
file. Itself, it may make use of an http-get function defined in yet
another library module.

I would like to avoid the case where each function signature needs to
have a required argument (the api_key and maybe others too) that could
be added much more elegantly by looking up a global variable read from
the configuration file.  For example, for the functions documented
here (http://developer.marklogic.com/pubs/5.0/apidocs/ec2-2009-11-30.html)
each function has always the same three arguments that serve to
identify the caller. In my case, there can be three such arguments,
but only one is required.

instead of this
d:get-data($api_key as xs:string, $secret as xs:string?, $from as
xs:string, $to as xs:string) as element(result) {};

I'd like this
d:get-data($from as xs:string, $to as xs:string) as element(result) {
http:get($config:url, $config:api_key, $config:secret, $from, $to) };

where the authentication arguments would be retrieved from the
configuration file when necessary and added to the http get request
inside the function body.


so, would it be advisable to have this (where only application.xqy has
all information necessary, but minimal inclusion takes place)

- application.xqy that includes
  - configuration.xqy
  - library1.xqy
  - library2.xqy
  - lowlevelfunctions.xqy

or rather this (where each library module is independent as it
includes what's needed)

- application.xqy that includes
  - library1.xqy which includes
    - configuration.xqy
    - lowlevelfunctions.xqy
  - library2.xqy which includes
    - configuration.xqy
    - lowlevelfunctions.xqy

or still another scenario?

sorry if that sounds confusing,
Jakob.


More information about the talk mailing list