[xquery-talk] best practice for function design with many optional params

Jakob Fix jakob.fix at gmail.com
Thu Jan 26 05:54:48 PST 2012

> -----Original Message-----
> From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf
> Of Michael Kay
> Sent: Thursday, January 26, 2012 4:13 AM
> To: talk at x-query.com
> Subject: Re: [xquery-talk] best practice for function design with many
> optional params
> On 26/01/2012 08:13, Jakob Fix wrote:
>> Hello,
>> I'm confronted with the design of a function library where many
>> functions have loads of optional arguments.
>> I haven't really looked at maps (they are planned for XQuery 3.0 I
>> think), what would their advantage be over the node approach? Any
>> other ideas or pointers for more information?
> Maps provide a good solution to this requirement, but sadly there has
> been resistance to getting them into the XQuery language in 3.0
> timescales so you may have to wait a little longer. (Or, as with
> grouping and updates, hope that your chosen implementors are ahead of
> the standards curve.)
> If the optional parameters have values that are single strings, passing
> an element node with lots of attributes provides a suitable solution
> (it's equivalent to a map whose keys are QNames and whose associated
> values are strings). For more complex parameters this starts to break
> down, for example you can't pass nodes or function items this way. The
> other disadvantage of using nodes is that they carry a lot of baggage -
> identity, base URI, in-scope namespaces - which add cost and complexity
> without being in any way useful for this use case.
> Michael Kay
> Saxonica

On Thu, Jan 26, 2012 at 13:12, David Lee <dlee at calldei.com> wrote:
> Another common practice is to pass a sequence as the options.   Depending on
> what values this has to take it may work well or not.
> I've seen most commonly a sequence of strings naming boolean or enumerated
> options.
> -David
> ----------------------------------------
> David A. Lee
> dlee at calldei.com
> http://www.xmlsh.org

David, do you mean something along the lines of ('option-name-1',
'option-value-1', 'option-name-2', 'option-value-2', ...)? I would
think this would be quite hard to manage both on the calling side and
on the function side.

As my needs so far seem to be in the area of strings and integers, I
think I may go with the one element with attributes for each option
approach as suggested by Michael Kay. This seems to be a good
compromise with regard to verbosity, is reasonably similar to maps, so
a future update wouldn't be too complex; also I'd like to avoid
vendor-dependency where possible.


More information about the talk mailing list