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.