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.lett...@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.
>
>
