From geert.josten at dayon.nl Mon Jan 2 23:13:16 2012 From: geert.josten at dayon.nl (Geert Josten) Date: Tue, 3 Jan 2012 08:13:16 +0100 Subject: [xquery-talk] xquery library design In-Reply-To: References: Message-ID: <964fdd18bb780ef223701e6d012aacd3@mail.gmail.com> In more classical languages one would initialize the library or object with the given config. Some implementations provide extensions for that, but I'd prefer to refrain from that. Other approaches are to add listeners or provide other kind of callback functions somehow. But that would also require you to maintain some kind of state in the library, which is difficult without using side-effects. So, I think a global is easiest, like suggested by Mike. His other suggestion to pass in only one argument that provides all config/context info makes sense too. I see no reason why not to pass around an entire config element structure holding all a function might need. Kind regards, Geert -----Oorspronkelijk bericht----- Van: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] Namens Jakob Fix Verzonden: woensdag 28 december 2011 0:13 Aan: talk at x-query.com Onderwerp: [xquery-talk] xquery library design 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. _______________________________________________ talk at x-query.com http://x-query.com/mailman/listinfo/talk From james.fuller.2007 at gmail.com Fri Jan 13 01:42:19 2012 From: james.fuller.2007 at gmail.com (James Fuller) Date: Fri, 13 Jan 2012 10:42:19 +0100 Subject: [xquery-talk] [ANN] xquerydoc v0.1 released Message-ID: xquerydoc v0.1 is released, includes * variety of small fixes * recursive directory processing * robust run script for unix/mac platforms * installer this version now will recursively process, looking for xquery files and more 'api like' html output ... its much more robust (I hope!) then initial release. I would appreciate any help in testing ... also adding windows support and markdown output later on today, but could do with someone willing to help me test windows platform ... any volunteers ? Jim Fuller From joewiz at gmail.com Fri Jan 13 13:37:35 2012 From: joewiz at gmail.com (Joe Wicentowski) Date: Fri, 13 Jan 2012 16:37:35 -0500 Subject: [xquery-talk] [ANN] xquerydoc v0.1 released In-Reply-To: References: Message-ID: Hi Jim, I think you forgot to include a URL? Joe On Fri, Jan 13, 2012 at 4:42 AM, James Fuller wrote: > xquerydoc v0.1 is released, includes > > * variety of small fixes > * recursive directory processing > * robust run script for unix/mac platforms > * installer > > this version now will recursively process, looking for xquery files > and more 'api like' html output ... its much more robust (I hope!) > then initial release. > > I would appreciate any help in testing ... also adding windows support > and markdown output later on today, but could do with someone willing > to help me test windows platform ... any volunteers ? > > Jim Fuller From james.fuller.2007 at gmail.com Fri Jan 13 15:28:05 2012 From: james.fuller.2007 at gmail.com (James Fuller) Date: Sat, 14 Jan 2012 00:28:05 +0100 Subject: [xquery-talk] [ANN] xquerydoc v0.1 released In-Reply-To: References: Message-ID: ummm ... indeed xquerydoc url https://github.com/xquery/xquerydoc generate xquery documentation (thx Joe!) J On Fri, Jan 13, 2012 at 10:37 PM, Joe Wicentowski wrote: > Hi Jim, > > I think you forgot to include a URL? > > Joe > > On Fri, Jan 13, 2012 at 4:42 AM, James Fuller > wrote: >> xquerydoc v0.1 is released, includes >> >> * variety of small fixes >> * recursive directory processing >> * robust run script for unix/mac platforms >> * installer >> >> this version now will recursively process, looking for xquery files >> and more 'api like' html output ... its much more robust (I hope!) >> then initial release. >> >> I would appreciate any help in testing ... also adding windows support >> and markdown output later on today, but could do with someone willing >> to help me test windows platform ... any volunteers ? >> >> Jim Fuller From jidanni at jidanni.org Tue Jan 17 19:35:30 2012 From: jidanni at jidanni.org (jidanni at jidanni.org) Date: Wed, 18 Jan 2012 11:35:30 +0800 Subject: [xquery-talk] <<=, >>= Message-ID: <87r4yxn0n1.fsf@jidanni.org> Hmmm, http://www.w3.org/TR/xquery-30/ : +-------------------------------------------------------------------------+ |[98] |ValueComp | ::= |"eq" | "ne" | "lt" | "le" | "gt" | "ge" | |-------+--------------+---------+----------------------------------------| |[97] |GeneralComp | ::= |"=" | "!=" | "<" | "<=" | ">" | ">=" | |-------+--------------+---------+----------------------------------------| |[99] |NodeComp | ::= |"is" | "<<" | ">>" | +-------------------------------------------------------------------------+ Well, if there also was <<=, >>= that would be marvelous. Hmmm, then all that would be missing is an "nis". From jakob.fix at gmail.com Thu Jan 26 00:13:47 2012 From: jakob.fix at gmail.com (Jakob Fix) Date: Thu, 26 Jan 2012 09:13:47 +0100 Subject: [xquery-talk] best practice for function design with many optional params Message-ID: Hello, I'm confronted with the design of a function library where many functions have loads of optional arguments. I understand in XQuery I can create any number of functions with the same name as long as the signature is differentiated by the number of arguments. This is cumbersome if I have many arguments, and also if there is no precedence (i.e. the third optional param could appear on its own without the first or second param being required). f:func( $req1, $opt1, $opt2, $opt3 ) f:func( $req1, $opt1 ) f:func( $req1, $opt1, $opt2 ) would work, but what about f:func( $req1, $opt2 ) f:func( $req1, $opt2, $opt3 ) f:func( $req1, $opt3 ) another option would be to use a sequence: f:func( $req1, $seq1 as item()* ) but it's still difficult to make sense of parameters passed as they cannot be identified as no name and position is non-significative the "least evil" solution seems to be for me right now: f:func( $req1, $params as element(params) ) where $params := abc advantage here is to have explicit parameter names and it's easy to make sense of them. but drawbacks are it's quite more verbose, and all the verification has to be done by the function body 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? Thanks, Jakob. From mike at saxonica.com Thu Jan 26 01:13:06 2012 From: mike at saxonica.com (Michael Kay) Date: Thu, 26 Jan 2012 09:13:06 +0000 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: References: Message-ID: <4F211922.4060104@saxonica.com> 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 From dlee at calldei.com Thu Jan 26 04:12:13 2012 From: dlee at calldei.com (David Lee) Date: Thu, 26 Jan 2012 07:12:13 -0500 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: <4F211922.4060104@saxonica.com> References: <4F211922.4060104@saxonica.com> Message-ID: <015a01ccdc23$bd9d9910$38d8cb30$@calldei.com> 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 -----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 _______________________________________________ talk at x-query.com http://x-query.com/mailman/listinfo/talk From jakob.fix at gmail.com Thu Jan 26 05:54:48 2012 From: jakob.fix at gmail.com (Jakob Fix) Date: Thu, 26 Jan 2012 14:54:48 +0100 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: <015a01ccdc23$bd9d9910$38d8cb30$@calldei.com> References: <4F211922.4060104@saxonica.com> <015a01ccdc23$bd9d9910$38d8cb30$@calldei.com> Message-ID: > -----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 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. Thanks, Jakob. From dlee at calldei.com Thu Jan 26 07:35:59 2012 From: dlee at calldei.com (David Lee) Date: Thu, 26 Jan 2012 10:35:59 -0500 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: References: <4F211922.4060104@saxonica.com> <015a01ccdc23$bd9d9910$38d8cb30$@calldei.com> Message-ID: <023c01ccdc40$34be82e0$9e3b88a0$@calldei.com> 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. Thanks, Jakob. --------------------------------------------- Yes Jakob that was the approach was referring. example: mymodule:search( doc("file.xml") , ( "case-sensitive" , "ascending" ) ) This might be equivalent to : mymodule:search( doc("file.xml") , ) 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 parse. 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 http://www.xmlsh.org _______________________________________________ talk at x-query.com http://x-query.com/mailman/listinfo/talk From lists at fgeorges.org Thu Jan 26 08:54:21 2012 From: lists at fgeorges.org (Florent Georges) Date: Thu, 26 Jan 2012 16:54:21 +0000 (GMT) Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: <015a01ccdc23$bd9d9910$38d8cb30$@calldei.com> References: <4F211922.4060104@saxonica.com> <015a01ccdc23$bd9d9910$38d8cb30$@calldei.com> Message-ID: <1327596861.36827.YahooMailNeo@web29019.mail.ird.yahoo.com> David Lee wrote: ? Hi, > Another common practice is to pass a sequence as the options. ? The main drawback I see with this approach is that it copes very badly with empty values (where the value is the empty sequence) and with sequences (where a value can be a sequence). ?And the behaviour can be very surprising (and hard to debug) when one passes an empty sequence or a sequence of more than one items by mistake. ? As Mike said, maps would be perfect here... ? Regards, --? Florent Georges http://fgeorges.org/ http://h2oconsulting.be/ From james.fuller.2007 at gmail.com Thu Jan 26 11:31:34 2012 From: james.fuller.2007 at gmail.com (James Fuller) Date: Thu, 26 Jan 2012 20:31:34 +0100 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: References: Message-ID: On Thu, Jan 26, 2012 at 9:13 AM, Jakob Fix wrote: > Hello, > > I'm confronted with the design of a function library where many > functions have loads of optional arguments. > > I understand in XQuery I can create any number of functions with the > same name as long as the signature is differentiated by the number of > arguments. This is cumbersome if I have many arguments, and also if > there is no precedence (i.e. the third optional param could appear on > its own without the first or second param being required). > > f:func( $req1, $opt1, $opt2, $opt3 ) > f:func( $req1, $opt1 ) > f:func( $req1, $opt1, $opt2 ) > > would work, but what about > > f:func( $req1, $opt2 ) > f:func( $req1, $opt2, $opt3 ) > f:func( $req1, $opt3 ) > > another option would be to use a sequence: > > f:func( $req1, $seq1 as item()* ) > > but it's still difficult to make sense of parameters passed as they > cannot be identified as no name and position is non-significative > > the "least evil" solution seems to be for me right now: > > f:func( $req1, $params as element(params) ) > > where $params := abc > advantage here is to have explicit parameter names and it's easy to > make sense of them. > but drawbacks are it's quite more verbose, and all the verification > has to be done by the function body > > 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? as others have said, maps would be ideal ... past that, I think in any programming language, its kind of a 'bad smell' when a function has a very long signature ... are you sure all these options are intrinsic to your function (in this sense its analagous to the questions we ask ourselves in OO lang when defining a class, its members and functions). I would suggest; * can you decompose your function into several functions ? this can have a beneficial decoupling * the approach MKay defined (e.g. element with lots of attributes) is the best way to do it, but make sure you group your options along logical lines (perhaps cross cutting across several functions) * w/o seeing your actual function logic, you may find it useful to pass in a function versus a bunch of variables * can is the primary data ($req1) your function is working on be decomposed ... it maybe that you are trying to achieve a lot of things * have you tried unit testing ... this can help discover the right 'grain' your functions should work at e.g. I find myself often refactoring a function when I have unit tests in affect ... also unit tests can help you look at a functions responsibility from different angles gl, J From rpbourret at rpbourret.com Thu Jan 26 12:07:06 2012 From: rpbourret at rpbourret.com (Ronald Bourret) Date: Thu, 26 Jan 2012 12:07:06 -0800 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: <1327596861.36827.YahooMailNeo@web29019.mail.ird.yahoo.com> References: <4F211922.4060104@saxonica.com> <015a01ccdc23$bd9d9910$38d8cb30$@calldei.com> <1327596861.36827.YahooMailNeo@web29019.mail.ird.yahoo.com> Message-ID: <4F21B26A.30801@rpbourret.com> The other obvious variation is to pass a single node with children representing the optional variables. This is similar to the attribute approach Michael suggests, but allows for complex arguments. It also handles sequences, as these can be wrapped in a child. For example: Ron
123123 Main Mainville CA
333-333-3333 444-444-4444
-- Ron Florent Georges wrote: > David Lee wrote: > > Hi, > >> Another common practice is to pass a sequence as the options. > > The main drawback I see with this approach is that it copes very > badly with empty values (where the value is the empty sequence) > and with sequences (where a value can be a sequence). And the > behaviour can be very surprising (and hard to debug) when one > passes an empty sequence or a sequence of more than one items by > mistake. > > As Mike said, maps would be perfect here... > > Regards, > > -- > Florent Georges > http://fgeorges.org/ > http://h2oconsulting.be/ > > _______________________________________________ > talk at x-query.com > http://x-query.com/mailman/listinfo/talk > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1416 / Virus Database: 2109/4766 - Release Date: 01/25/12 > > > From jakob.fix at gmail.com Thu Jan 26 14:04:13 2012 From: jakob.fix at gmail.com (Jakob Fix) Date: Thu, 26 Jan 2012 23:04:13 +0100 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: References: Message-ID: On Thu, Jan 26, 2012 at 20:31, James Fuller wrote: > On Thu, Jan 26, 2012 at 9:13 AM, Jakob Fix wrote: >> Hello, >> >> I'm confronted with the design of a function library where many >> functions have loads of optional arguments. >> >> I understand in XQuery I can create any number of functions with the >> same name as long as the signature is differentiated by the number of >> arguments. This is cumbersome if I have many arguments, and also if >> there is no precedence (i.e. the third optional param could appear on >> its own without the first or second param being required). >> >> f:func( $req1, $opt1, $opt2, $opt3 ) >> f:func( $req1, $opt1 ) >> f:func( $req1, $opt1, $opt2 ) >> >> would work, but what about >> >> f:func( $req1, $opt2 ) >> f:func( $req1, $opt2, $opt3 ) >> f:func( $req1, $opt3 ) >> >> another option would be to use a sequence: >> >> f:func( $req1, $seq1 as item()* ) >> >> but it's still difficult to make sense of parameters passed as they >> cannot be identified as no name and position is non-significative >> >> the "least evil" solution seems to be for me right now: >> >> f:func( $req1, $params as element(params) ) >> >> where $params := abc >> advantage here is to have explicit parameter names and it's easy to >> make sense of them. >> but drawbacks are it's quite more verbose, and all the verification >> has to be done by the function body >> >> 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? > > as others have said, maps would be ideal ... > > past that, I think in any programming language, its kind of a 'bad > smell' when a function has a very long signature ... ?are you sure all > these options are intrinsic to your function (in this sense its > analagous to the questions we ask ourselves in OO lang when defining a > class, its members and functions). > > I would suggest; > > * can you decompose your function into several functions ? this can > have a beneficial decoupling > > * the approach MKay defined (e.g. element with lots of attributes) is > the best way to do it, but make sure you group your options along > logical lines (perhaps cross cutting across several functions) > > * w/o seeing your actual function logic, you may find it useful to > pass in a function versus a bunch of variables > > * can is the primary data ($req1) your function is working on be > decomposed ... it maybe that you are trying to achieve a lot of things > > * have you tried unit testing ... this can help discover the right > 'grain' your functions should work at e.g. I find myself often > refactoring a function when I have unit tests in affect ... also unit > tests can help you look at a functions responsibility from different > angles > > gl, J Jim, thanks for your input. right now, I'm mapping an existing api to xquery, therefore I'd like to stick to the original signatures if at all possible. Later on, convenience functions could be imagined, of course. I do use unit testing (xqut right now, although I'm tempted to give x-ray a try, both admittedly MarkLogic-specific). cheers, Jakob. From jakob.fix at gmail.com Thu Jan 26 14:26:54 2012 From: jakob.fix at gmail.com (Jakob Fix) Date: Thu, 26 Jan 2012 23:26:54 +0100 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: <4F21B26A.30801@rpbourret.com> References: <4F211922.4060104@saxonica.com> <015a01ccdc23$bd9d9910$38d8cb30$@calldei.com> <1327596861.36827.YahooMailNeo@web29019.mail.ird.yahoo.com> <4F21B26A.30801@rpbourret.com> Message-ID: Ronald, that was my initial approach that I quite liked because as you said - it allows for complex values - the element name and its contents are nice vehicles for key and value - it's easy to evaluate optional elements (if the child element exists, the parameter has been supllied, otherwise, we don't care) - in some scenarios, one could supplement each parameter with attributes indicating default values and types 11 drawbacks: - verbosity (which is why I did take a liking to the attribute on the single element approach) - all the "baggage" as mentioned by Michael Kay in his message, although I think I could live with that for now All in all, it seems there's no perfect solution, so I'll have to figure out what the most acceptable approach is for me until maps come along. Thanks for everybody's input, Jakob. On Thu, Jan 26, 2012 at 21:07, Ronald Bourret wrote: > The other obvious variation is to pass a single node with children > representing the optional variables. This is similar to the attribute > approach Michael suggests, but allows for complex arguments. It also handles > sequences, as these can be wrapped in a child. > > For example: > > > ? Ron > ?
> ? ? ?123123 Main > ? ? ?Mainville > ? ? ?CA > ?
> ? > ? > ? ? ? > ? ? ?333-333-3333 > ? ? ?444-444-4444 > ? >
> > -- Ron > > Florent Georges wrote: >> >> David Lee wrote: >> >> ?Hi, >> >>> Another common practice is to pass a sequence as the options. >> >> >> ?The main drawback I see with this approach is that it copes very >> badly with empty values (where the value is the empty sequence) >> and with sequences (where a value can be a sequence). ?And the >> behaviour can be very surprising (and hard to debug) when one >> passes an empty sequence or a sequence of more than one items by >> mistake. >> >> ?As Mike said, maps would be perfect here... >> >> ?Regards, >> >> -- >> Florent Georges >> http://fgeorges.org/ >> http://h2oconsulting.be/ >> >> _______________________________________________ >> talk at x-query.com >> http://x-query.com/mailman/listinfo/talk >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1416 / Virus Database: 2109/4766 - Release Date: 01/25/12 >> >> >> > _______________________________________________ > talk at x-query.com > http://x-query.com/mailman/listinfo/talk From james.fuller.2007 at gmail.com Thu Jan 26 15:06:15 2012 From: james.fuller.2007 at gmail.com (James Fuller) Date: Fri, 27 Jan 2012 00:06:15 +0100 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: References: Message-ID: > thanks for your input. right now, I'm mapping an existing api to > xquery, therefore I'd like to stick to the original signatures if at > all possible. Later on, convenience functions could be imagined, of ah I see ... it could be that the API needed to be designed in the manner it is for other reasons, unsure, in any event this is a good example of why designing API's is so important. > course. ?I do use unit testing (xqut right now, although I'm tempted > to give x-ray a try, both admittedly MarkLogic-specific). I am using x-ray ... though both are excellent. J > > cheers, > Jakob. From mike at saxonica.com Thu Jan 26 16:00:54 2012 From: mike at saxonica.com (Michael Kay) Date: Fri, 27 Jan 2012 00:00:54 +0000 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: References: Message-ID: <4F21E936.7020907@saxonica.com> Jim Fuller>I think in any programming language, its kind of a 'bad smell' when a function has a very long signature ... are you sure all these options are intrinsic to your function I think there's a difference between "having lots of options" and "having a very long signature". In languages where functions always have positional arguments, the challenge is to define a function signature that accepts lots of options without requiring lots of positional arguments, and that's what we are discussing here. Using a map argument is essentially a workaround for the fact that the language does not offer named parameters on calls. I can think of plenty of cases where having lots of options is perfectly respectable. For example I can think of at least a dozen options one might want to specify to the deep-equal() function. It's only because XQuery doesn't provide a convenient way of providing such options that they aren't actually available. (The regular expression functions, incidentally, provide options through the flags argument as a set of boolean options each represented by one letter in a string: it's a crude mechanism, but it works.) Michael Kay Saxonica From james.fuller.2007 at gmail.com Thu Jan 26 21:11:42 2012 From: james.fuller.2007 at gmail.com (James Fuller) Date: Fri, 27 Jan 2012 06:11:42 +0100 Subject: [xquery-talk] best practice for function design with many optional params In-Reply-To: <4F21E936.7020907@saxonica.com> References: <4F21E936.7020907@saxonica.com> Message-ID: On Fri, Jan 27, 2012 at 1:00 AM, Michael Kay wrote: > Jim Fuller>I think in any programming language, its kind of a 'bad smell' > when a function has a very long signature ... are you sure all these options > are intrinsic to your function > > I think there's a difference between "having lots of options" and "having a > very long signature". In languages where functions always have positional sure, I think we are in agreement > arguments, the challenge is to define a function signature that accepts lots > of options without requiring lots of positional arguments, and that's what > we are discussing here. Using a map argument is essentially a workaround for > the fact that the language does not offer named parameters on calls. > > I can think of plenty of cases where having lots of options is perfectly > respectable. For example I can think of at least a dozen options one might > want to specify to the deep-equal() function. It's only because XQuery > doesn't provide a convenient way of providing such options that they aren't > actually available. sure, perhaps 'bad smell' was too strong a term, but in general I think one should avoid very long signatures if possible > (The regular expression functions, incidentally, provide options through the > flags argument as a set of boolean options each represented by one letter in > a string: it's a crude mechanism, but it works.) I am used to this kind of thing but I think we are all in agreement that maps would have been a nice thing. J From jakub.maly at atlas.cz Sat Jan 28 08:56:30 2012 From: jakub.maly at atlas.cz (Jakub Maly) Date: Sat, 28 Jan 2012 17:56:30 +0100 Subject: [xquery-talk] XQuery 3.0 and maps in Saxon Message-ID: <20120128175630.F6DF946B@atlas.cz> (At first, I apologize to the members of XSL list, from which I was referred here, for getting the same message twice). Hello, I would like to experiment with map features in Saxon (http://www.saxonica.com/documentation/expressions/xpath30maps.xml), but I am unable to get past query compilation. Maybe I am missing some parameter or I use a wrong namespace, but I just can't find the right answer. This is my query code: xquery version "3.0"; (: i have also tried http://www.w3.org/2005/xpath-functions/map, no difference :) import module namespace map = "http://ns.saxonica.com/map"; map:get(map { 1 := 'aaa'}, 1) invoked from command line: "c:\Program Files\Saxonica\SaxonEE9.4N\bin\Query.exe" -s:play.xml -q:play2.xq" -qversion:3.0 The commands ends with error: Cannot locate module for namespace "http://ns.saxonica.com/map" When I leave out the module namespace map declaration, the error is Prefix map has not been declared, so I assume the namespace declaration must be there... ________________________________________ Jakub Mal? Ph. D. candidate XML Research Group Department of Software Engineering Faculty of Mathematics and Physics Charles University in Prague, Czech Republic www.jakubmaly.cz From mike at saxonica.com Sat Jan 28 10:52:04 2012 From: mike at saxonica.com (Michael Kay) Date: Sat, 28 Jan 2012 18:52:04 +0000 Subject: [xquery-talk] XQuery 3.0 and maps in Saxon In-Reply-To: <20120128175630.F6DF946B@atlas.cz> References: <20120128175630.F6DF946B@atlas.cz> Message-ID: <4F2443D4.20405@saxonica.com> On 28/01/2012 16:56, Jakub Maly wrote: > (At first, I apologize to the members of XSL list, from which I was referred here, for getting the same message twice). > Hello, > I would like to experiment with map features in Saxon (http://www.saxonica.com/documentation/expressions/xpath30maps.xml), but I am unable to get past query compilation. Maybe I am missing some parameter or I use a wrong namespace, but I just can't find the right answer. I was rather hoping that the W3C spec would be out before the Saxon implementation, but it got held up because people in the XQuery WG didn't want it in XQuery 3.0. The net result is that there's a shortage of documentation. The page at http://www.saxonica.com/documentation/extensions/map.xml wrongly gives the namespace as "http://ns.saxonica.com/map". In fact, in the over-optimistic belief that the spec was about to be approved by W3C, I moved the functions into the namespace "http://www.w3.org/2005/xpath-functions/map". > This is my query code: > > xquery version "3.0"; > (: i have also tried http://www.w3.org/2005/xpath-functions/map, no difference :) > import module namespace map = "http://ns.saxonica.com/map"; > map:get(map { 1 := 'aaa'}, 1) > For vendor-defined extension functions in Saxon, you don't need an import module, but you do need to declare the namespace. So it should be xquery version "3.0"; declare namespace map := "http://www.w3.org/2005/xpath-functions/map"; map:get(map { 1 := 'aaa'}, 1) Michael Kay Saxonica From mike at saxonica.com Sat Jan 28 11:28:19 2012 From: mike at saxonica.com (Michael Kay) Date: Sat, 28 Jan 2012 19:28:19 +0000 Subject: [xquery-talk] XQuery 3.0 and maps in Saxon In-Reply-To: <4F2443D4.20405@saxonica.com> References: <20120128175630.F6DF946B@atlas.cz> <4F2443D4.20405@saxonica.com> Message-ID: <4F244C53.20503@saxonica.com> On 28/01/2012 18:52, Michael Kay wrote: > On 28/01/2012 16:56, Jakub Maly wrote: >> (At first, I apologize to the members of XSL list, from which I was >> referred here, for getting the same message twice). >> Hello, >> I would like to experiment with map features in Saxon >> (http://www.saxonica.com/documentation/expressions/xpath30maps.xml), >> but I am unable to get past query compilation. Maybe I am missing >> some parameter or I use a wrong namespace, but I just can't find the >> right answer. > I was rather hoping that the W3C spec would be out before the Saxon > implementation, but it got held up because people in the XQuery WG > didn't want it in XQuery 3.0. The net result is that there's a > shortage of documentation. > I have remedied the lack of documentation by placing a specification of maps as implemented in Saxon-PE 9.4 at http://dev.saxonica.com/blog/mike/2012/01/#000188 Any resemblance to any spec that might be published by some future W3C working group is entirely serendipitous. Michael Kay Saxonica From jakub.maly at atlas.cz Sat Jan 28 12:25:35 2012 From: jakub.maly at atlas.cz (Jakub Maly) Date: Sat, 28 Jan 2012 21:25:35 +0100 Subject: [xquery-talk] XQuery 3.0 and maps in Saxon In-Reply-To: <4F244C53.20503@saxonica.com> References: <20120128175630.F6DF946B@atlas.cz> <4F2443D4.20405@saxonica.com> <4F244C53.20503@saxonica.com> Message-ID: <00b401ccddfa$fde0ea80$f9a2bf80$@atlas.cz> Thank you both for a quick answer and especially for very helpful posted material. Jakub. -----Original Message----- From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf Of Michael Kay Sent: Saturday, January 28, 2012 8:28 PM To: talk at x-query.com Subject: Re: [xquery-talk] XQuery 3.0 and maps in Saxon On 28/01/2012 18:52, Michael Kay wrote: > On 28/01/2012 16:56, Jakub Maly wrote: >> (At first, I apologize to the members of XSL list, from which I was >> referred here, for getting the same message twice). >> Hello, >> I would like to experiment with map features in Saxon >> (http://www.saxonica.com/documentation/expressions/xpath30maps.xml), >> but I am unable to get past query compilation. Maybe I am missing >> some parameter or I use a wrong namespace, but I just can't find the >> right answer. > I was rather hoping that the W3C spec would be out before the Saxon > implementation, but it got held up because people in the XQuery WG > didn't want it in XQuery 3.0. The net result is that there's a > shortage of documentation. > I have remedied the lack of documentation by placing a specification of maps as implemented in Saxon-PE 9.4 at http://dev.saxonica.com/blog/mike/2012/01/#000188 Any resemblance to any spec that might be published by some future W3C working group is entirely serendipitous. Michael Kay Saxonica _______________________________________________ talk at x-query.com http://x-query.com/mailman/listinfo/talk From jakub.maly at atlas.cz Sat Jan 28 15:24:51 2012 From: jakub.maly at atlas.cz (Jakub Maly) Date: Sun, 29 Jan 2012 00:24:51 +0100 Subject: [xquery-talk] XQuery 3.0 and maps in Saxon In-Reply-To: <4F244C53.20503@saxonica.com> References: <20120128175630.F6DF946B@atlas.cz> <4F2443D4.20405@saxonica.com> <4F244C53.20503@saxonica.com> Message-ID: <00c701ccde14$0911b790$1b3526b0$@atlas.cz> A follow-up question: I would like to call XQuery queries from XSLT stylesheet, I am using saxon:import-query, but with XQuery 3.0, Saxon is not happy: it outputs an error "XQuery 3.0 was not enabled when invoking Saxon" - can the -qversion:3.0 be somehow propagated to the XQuery processor from the XSLT? Jakub. -----Original Message----- From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf Of Michael Kay Sent: Saturday, January 28, 2012 8:28 PM To: talk at x-query.com Subject: Re: [xquery-talk] XQuery 3.0 and maps in Saxon On 28/01/2012 18:52, Michael Kay wrote: > On 28/01/2012 16:56, Jakub Maly wrote: >> (At first, I apologize to the members of XSL list, from which I was >> referred here, for getting the same message twice). >> Hello, >> I would like to experiment with map features in Saxon >> (http://www.saxonica.com/documentation/expressions/xpath30maps.xml), >> but I am unable to get past query compilation. Maybe I am missing >> some parameter or I use a wrong namespace, but I just can't find the >> right answer. > I was rather hoping that the W3C spec would be out before the Saxon > implementation, but it got held up because people in the XQuery WG > didn't want it in XQuery 3.0. The net result is that there's a > shortage of documentation. > I have remedied the lack of documentation by placing a specification of maps as implemented in Saxon-PE 9.4 at http://dev.saxonica.com/blog/mike/2012/01/#000188 Any resemblance to any spec that might be published by some future W3C working group is entirely serendipitous. Michael Kay Saxonica _______________________________________________ talk at x-query.com http://x-query.com/mailman/listinfo/talk From mike at saxonica.com Sun Jan 29 10:32:55 2012 From: mike at saxonica.com (Michael Kay) Date: Sun, 29 Jan 2012 18:32:55 +0000 Subject: [xquery-talk] XQuery 3.0 and maps in Saxon In-Reply-To: <00c701ccde14$0911b790$1b3526b0$@atlas.cz> References: <20120128175630.F6DF946B@atlas.cz> <4F2443D4.20405@saxonica.com> <4F244C53.20503@saxonica.com> <00c701ccde14$0911b790$1b3526b0$@atlas.cz> Message-ID: <4F2590D7.3080004@saxonica.com> On 28/01/2012 23:24, Jakub Maly wrote: > A follow-up question: I would like to call XQuery queries from XSLT > stylesheet, I am using saxon:import-query, but with XQuery 3.0, Saxon is not > happy: it outputs an error "XQuery 3.0 was not enabled when invoking Saxon" > - can the -qversion:3.0 be somehow propagated to the XQuery processor from > the XSLT? > > I would encourage you to use the saxon-help list for a question that is quite so product-specific. I haven't tested this, but assuming you are running from the net.sf.saxon.Transform command line, try setting --queryVersion:3.0 Michael Kay Saxonica From gkholman at CraneSoftwrights.com Mon Jan 30 05:33:00 2012 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Mon, 30 Jan 2012 08:33:00 -0500 Subject: [xquery-talk] How can I retrive namespace defined in xml In-Reply-To: References: Message-ID: <7.0.1.0.2.20120130083035.023337d8@wheresmymailserver.com> At 2012-01-30 18:56 +0530, Kunal Chauhan wrote: >Hi, > >I want to retrive namespace that are defined in xml file. >so how can I retrive it ? > >for Eg. > > > > > > > > >I want to retrive each namespace defined in xml file. >I am able to retrive each and every attribute. but can't retrive namespace. >so how can I get that ???? A combination of two calls using an element argument for context: in-scope-prefixes( $element ) - returns a sequence of namespace prefixes namespace-uri-for-prefix( $prefix, $element ) - returns a URI of namespace I hope this helps. . . . . . . . . . . Ken -- Contact us for world-wide XML consulting and instructor-led training Free 5-hour video lecture: XSLT/XPath 1.0 & 2.0 http://ude.my/uoui9h Crane Softwrights Ltd. http://www.CraneSoftwrights.com/q/ G. Ken Holman mailto:gkholman at CraneSoftwrights.com Google+ profile: https://plus.google.com/116832879756988317389/about Legal business disclaimers: http://www.CraneSoftwrights.com/legal From mpilman at student.ethz.ch Mon Jan 30 05:34:54 2012 From: mpilman at student.ethz.ch (Markus Pilman) Date: Mon, 30 Jan 2012 14:34:54 +0100 Subject: [xquery-talk] How can I retrive namespace defined in xml In-Reply-To: References: Message-ID: Hi, declare function functx:namespaces-in-use ( $root as node()? ) as xs:anyURI* { distinct-values( $root/descendant-or-self::*/(.|@*)/namespace-uri(.)) } ; You can look it up here: http://www.xqueryfunctions.com/xq/functx_namespaces-in-use.html Hope this helps Markus On Mon, Jan 30, 2012 at 2:26 PM, Kunal Chauhan wrote: > > Hi, > > I want to retrive namespace that are defined in xml file. > so how can I retrive it ? > > for Eg. > > > > > > > > > I want to retrive each namespace defined in xml file. > I am able to retrive each and every attribute. but can't retrive namespace. > so how can I get that ???? > > Thanks, > > -- > Kunal Chauhan > mail4ck at gmail.com > [+918655517141] > [+919904983614] > > > _______________________________________________ > talk at x-query.com > http://x-query.com/mailman/listinfo/talk From davidc at nag.co.uk Mon Jan 30 05:47:00 2012 From: davidc at nag.co.uk (David Carlisle) Date: Mon, 30 Jan 2012 13:47:00 +0000 Subject: [xquery-talk] How can I retrive namespace defined in xml In-Reply-To: References: Message-ID: <4F269F54.4010903@nag.co.uk> On 30/01/2012 13:34, Markus Pilman wrote: > Hi, > > declare function functx:namespaces-in-use > ( $root as node()? ) as xs:anyURI* { > > distinct-values( > $root/descendant-or-self::*/(.|@*)/namespace-uri(.)) > } ; > > You can look it up here: > http://www.xqueryfunctions.com/xq/functx_namespaces-in-use.html > > Hope this helps > > Markus > That would only return the namespaces of elements and attribute, not namespaces declared but not used or declared but only used in content (such as for types in XSD schema, or namespaces declared in XSLT but only used in variable and function names). To find all declared namespaces you want to use the namespace axis in those products that support it or the fn:in-scope-prefixes and fn:namespace-uri-for-prefix functions otherwise. David -- google plus: https:/profiles.google.com/d.p.carlisle ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________