Hi, I would like to ask some advice. For my Origami[1] library I'm exploring different ways of providing more powerful selectors for nodes in a template document. As this is for a templating library I would like to offer string based selectors and am considering if I should go for CSS-style selectors or XPath selectors. I started on CSS selectors to be able to select nodes with selectors like "p#id" and "li.class" but to do this properly it involves quite a bit of string manipulation in order to support more advanced stuff. Being in a language that already has XPath in it, it would be much more natural and powerful to use XPath selectors. This led me to look at xquery:eval. So far I resisted using eval but the code is a lot simpler that way. Implementing CSS-style selectors would probably lead me down a path with a lot more ugly string manipulation. I'm aware that it's better to express these things in XQuery code and that is also possible. But it's so much nicer to read this: xf:extract(xf:select('li'), $doc) then this: xf:extract(function($node) { $node/li }, $doc) I'm interested in pros and cons of using xquery:eval with XPath string-selectors. How is the performance? Other downsides (such as being non-standard)? Thanks --Marc [1] https://github.com/xokomola/origami
Hi Marc, I have not used it, or even claim to understand it, but https://github.com/jpcs/transform.xq might give you some ideas. It avoids eval by using an EBNF to pre-generate an XPath parser in XQuery. /Andy On 13 November 2014 21:51, Marc van Grootel <marc.van.grootel@gmail.com> wrote:
Hi,
I would like to ask some advice.
For my Origami[1] library I'm exploring different ways of providing more powerful selectors for nodes in a template document.
As this is for a templating library I would like to offer string based selectors and am considering if I should go for CSS-style selectors or XPath selectors.
I started on CSS selectors to be able to select nodes with selectors like "p#id" and "li.class" but to do this properly it involves quite a bit of string manipulation in order to support more advanced stuff.
Being in a language that already has XPath in it, it would be much more natural and powerful to use XPath selectors. This led me to look at xquery:eval.
So far I resisted using eval but the code is a lot simpler that way. Implementing CSS-style selectors would probably lead me down a path with a lot more ugly string manipulation.
I'm aware that it's better to express these things in XQuery code and that is also possible. But it's so much nicer to read this:
xf:extract(xf:select('li'), $doc)
then this:
xf:extract(function($node) { $node/li }, $doc)
I'm interested in pros and cons of using xquery:eval with XPath string-selectors. How is the performance? Other downsides (such as being non-standard)?
Thanks
--Marc
Hi Andy, I've looked at it before. Seems like a huge machine for the job. I thought somewhere I read that performance on xquery:eval is really good and my very simplistic toy example did seem to perform quite well but I will need to do more experimenting. --Marc
Hi Marc, we use xquery:eval a lot. I think that reflexivity in a language is a very powerful and useful tool and in basex it's implemented quite well. The possibility to pass, in the parameter map, function items as parameters besides variables and context builds up a complete toolset allowing one to write elegant and dynamic workflows with very fec lines of code. In all our use cases we haven't encountered any performance issue and now it's even possible to set timeouts on the execution which is pretty handy to limit the time of a RESTXQ service which is something I still don't know how to do without eval. As per your use case, using XPath instead of CSS like selectors is something that I would do and it sounds pretty much reasonable. These are just my two cents. Cheers, M. On 13/11/2014 22:51, Marc van Grootel wrote:
Hi,
I would like to ask some advice.
For my Origami[1] library I'm exploring different ways of providing more powerful selectors for nodes in a template document.
As this is for a templating library I would like to offer string based selectors and am considering if I should go for CSS-style selectors or XPath selectors.
I started on CSS selectors to be able to select nodes with selectors like "p#id" and "li.class" but to do this properly it involves quite a bit of string manipulation in order to support more advanced stuff.
Being in a language that already has XPath in it, it would be much more natural and powerful to use XPath selectors. This led me to look at xquery:eval.
So far I resisted using eval but the code is a lot simpler that way. Implementing CSS-style selectors would probably lead me down a path with a lot more ugly string manipulation.
I'm aware that it's better to express these things in XQuery code and that is also possible. But it's so much nicer to read this:
xf:extract(xf:select('li'), $doc)
then this:
xf:extract(function($node) { $node/li }, $doc)
I'm interested in pros and cons of using xquery:eval with XPath string-selectors. How is the performance? Other downsides (such as being non-standard)?
Thanks
--Marc
Thanks Marco and Andy. I will go with XPath selectors and eval for now. John Snelson's library is indeed interesting and a while ago I tried the parser part for parsing XQuery into XML. I don't either understand it fully but it seems to do it's job. --Marc
One more thought on using eval: The xquery:eval function in BaseX has been optimized a lot over time. There are even use cases in which it will be evaluated faster than code without eval. An example: Query 1: for $db in ('with-index', 'without-index') return db:open($db)//*[text() = 'please'] Query 2: for $db in ('with-index', 'without-index') let $query := "//*[text() = 'please']" return xquery:eval($query, map { "": db:open($db) }) In these queries, two databases will be opened, one with text index, one without. In Query 1, it is (currently) not possible for the optimizer to rewrite the path expression for index access. This is different for Query 2: In the first call of xquery:eval, the index will be used, because it will be known at runtime that the referenced database has a text index. If one is aware of the obvious drawbacks of using eval (code injection, query strings cannot be parsed at compile time, ...), it can be a good choice (and there have already been thoughts to include it in a future version of the official W3C spec). Christian On Sat, Nov 15, 2014 at 1:27 PM, Marc van Grootel <marc.van.grootel@gmail.com> wrote:
Thanks Marco and Andy.
I will go with XPath selectors and eval for now. John Snelson's library is indeed interesting and a while ago I tried the parser part for parsing XQuery into XML. I don't either understand it fully but it seems to do it's job.
--Marc
On 16/11/2014 12:17, Christian Grün wrote:
If one is aware of the obvious drawbacks of using eval (code injection, query strings cannot be parsed at compile time, ...),
Hi Christian, according to the latter of these points I'd like to know whether there is a possibility of having an XQuery string validated from a syntactical viewpoint. I mean a sort of validate:xquery($qstr as xs:string) or xquery:check($querystr as xs:string, $ctx as map(*)). It could also be useful to know whether one could be able to implement it as a Java extension to basex and in that case where to start from? The GUI does it so I think it should be doable somehow, isn't it? ;-) Thanks a lot, Marco.
Hi Marco,
according to the latter of these points I'd like to know whether there is a possibility of having an XQuery string validated from a syntactical viewpoint.
currently no. It would certainly be doable, but I would like to hear more about the applications you have in mind. For example, I didn't quite get what you meant with the Java extensions? Christian
I mean a sort of validate:xquery($qstr as xs:string) or xquery:check($querystr as xs:string, $ctx as map(*)). It could also be useful to know whether one could be able to implement it as a Java extension to basex and in that case where to start from? The GUI does it so I think it should be doable somehow, isn't it? ;-) Thanks a lot, Marco.
Sorry for expressing myself with the wrong terminology. With Java extensions I meant writing my own Java code that somehow connects to the basex apis for parsing an XQuery and returns possible syntax errors mimicking the worflow of the basexgui. It then would be imported through javabindings mechanism of basex. What I was thinking about is a sort of HTML5 based version of the basexgui. Regards, Marco. On 17/11/2014 12:58, Christian Grün wrote:
Hi Marco,
according to the latter of these points I'd like to know whether there is a possibility of having an XQuery string validated from a syntactical viewpoint. currently no. It would certainly be doable, but I would like to hear more about the applications you have in mind. For example, I didn't quite get what you meant with the Java extensions?
Christian
I mean a sort of validate:xquery($qstr as xs:string) or xquery:check($querystr as xs:string, $ctx as map(*)). It could also be useful to know whether one could be able to implement it as a Java extension to basex and in that case where to start from? The GUI does it so I think it should be doable somehow, isn't it? ;-) Thanks a lot, Marco.
I see… Instead of immediately executing the query, you are only interested in parsing errors, right? Sounds reasonable. We could have some more thoughts on how the output of such a function (e.g. xquery:parse) could look like. Instead of returning an error, we could return an element that contains the information that would otherwise be bound to the error variables in a try/catch statement [1]: <error> <code>err:XPTY0004</code> <description>...</description> ... </error> Some other information could be returned if parsing was successful. – You are invited to add some more ideas in the corresponding GitHub issue [2]. Christian [1] http://www.w3.org/TR/xquery-31/#id-try-catch [2] https://github.com/BaseXdb/basex/issues/1028 On Mon, Nov 17, 2014 at 3:16 PM, Marco Lettere <marco.lettere@dedalus.eu> wrote:
Sorry for expressing myself with the wrong terminology. With Java extensions I meant writing my own Java code that somehow connects to the basex apis for parsing an XQuery and returns possible syntax errors mimicking the worflow of the basexgui. It then would be imported through javabindings mechanism of basex. What I was thinking about is a sort of HTML5 based version of the basexgui. Regards, Marco.
On 17/11/2014 12:58, Christian Grün wrote:
Hi Marco,
according to the latter of these points I'd like to know whether there is a possibility of having an XQuery string validated from a syntactical viewpoint.
currently no. It would certainly be doable, but I would like to hear more about the applications you have in mind. For example, I didn't quite get what you meant with the Java extensions?
Christian
I mean a sort of validate:xquery($qstr as xs:string) or xquery:check($querystr as xs:string, $ctx as map(*)). It could also be useful to know whether one could be able to implement it as a Java extension to basex and in that case where to start from? The GUI does it so I think it should be doable somehow, isn't it? ;-) Thanks a lot, Marco.
On 17/11/2014 16:32, Christian Grün wrote:
I see… Instead of immediately executing the query, you are only interested in parsing errors, right? Yes, exactly. Sounds reasonable. We could have some more thoughts on how the output of such a function (e.g. xquery:parse) could look like. Instead of returning an error, we could return an element that contains the information that would otherwise be bound to the error variables in a try/catch statement [1]:
<error> <code>err:XPTY0004</code> <description>...</description> ... </error>
Some other information could be returned if parsing was successful. – You are invited to add some more ideas in the corresponding GitHub issue [2]. I wouldn't know what else to add. It just sounds perfect to me. Thanks again! M.
Christian
[1] http://www.w3.org/TR/xquery-31/#id-try-catch [2] https://github.com/BaseXdb/basex/issues/1028
On Mon, Nov 17, 2014 at 3:16 PM, Marco Lettere <marco.lettere@dedalus.eu> wrote:
Sorry for expressing myself with the wrong terminology. With Java extensions I meant writing my own Java code that somehow connects to the basex apis for parsing an XQuery and returns possible syntax errors mimicking the worflow of the basexgui. It then would be imported through javabindings mechanism of basex. What I was thinking about is a sort of HTML5 based version of the basexgui. Regards, Marco.
On 17/11/2014 12:58, Christian Grün wrote:
Hi Marco,
according to the latter of these points I'd like to know whether there is a possibility of having an XQuery string validated from a syntactical viewpoint. currently no. It would certainly be doable, but I would like to hear more about the applications you have in mind. For example, I didn't quite get what you meant with the Java extensions?
Christian
I mean a sort of validate:xquery($qstr as xs:string) or xquery:check($querystr as xs:string, $ctx as map(*)). It could also be useful to know whether one could be able to implement it as a Java extension to basex and in that case where to start from? The GUI does it so I think it should be doable somehow, isn't it? ;-) Thanks a lot, Marco.
Hi Marco, Have fun using [1] with [2], Christian [1] http://docs.basex.org/wiki/XQuery_Module#xquery:parse [2] http://files.basex.org/releases/latest On Mon, Nov 17, 2014 at 3:16 PM, Marco Lettere <marco.lettere@dedalus.eu> wrote:
Sorry for expressing myself with the wrong terminology. With Java extensions I meant writing my own Java code that somehow connects to the basex apis for parsing an XQuery and returns possible syntax errors mimicking the worflow of the basexgui. It then would be imported through javabindings mechanism of basex. What I was thinking about is a sort of HTML5 based version of the basexgui. Regards, Marco.
On 17/11/2014 12:58, Christian Grün wrote:
Hi Marco,
according to the latter of these points I'd like to know whether there is a possibility of having an XQuery string validated from a syntactical viewpoint.
currently no. It would certainly be doable, but I would like to hear more about the applications you have in mind. For example, I didn't quite get what you meant with the Java extensions?
Christian
I mean a sort of validate:xquery($qstr as xs:string) or xquery:check($querystr as xs:string, $ctx as map(*)). It could also be useful to know whether one could be able to implement it as a Java extension to basex and in that case where to start from? The GUI does it so I think it should be doable somehow, isn't it? ;-) Thanks a lot, Marco.
participants (4)
-
Andy Bunce -
Christian Grün -
Marc van Grootel -
Marco Lettere