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

David Lee dlee at calldei.com
Thu Jan 26 07:35:59 PST 2012

Jakob Writes -->
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.



Yes Jakob that was the approach was referring.

mymodule:search(  doc("file.xml") , ( "case-sensitive" , "ascending" ) )

This might be equivalent to :

mymodule:search(  doc("file.xml") , 
	<options><case value='sensitive'><sort order='ascending'> </options>

I don't think either is particularly easier or harder to manage on the
caller or calling side.

The advantage of the simple list of strings is its a bit easier to write for
the caller, and is likely to be more efficient.  And the values don't have
to be strings, they could be any item type.
For example
    ( "max-lines" , 5 , "includes-element" , fn:QName( "foo" , "bar" ) )
However that then makes order important which in turn makes it harder to

The advantage of an options element is that its more structured, can contain
more complex data and you could even supply a schema for it if you wanted to
validate it at runtime.

xmlsh for example uses both approaches, sometimes interchangeably.   Command
line scripts take a list of option values.  Sometimes its easier for the
script to parse these as an element so they can be converted vi the
"xgetopts" command - http://www.xmlsh.org/CommandXgetopts

David A. Lee
dlee at calldei.com

talk at x-query.com

More information about the talk mailing list