- BaseX-Talk - mailman.uni-konstanz.de

RESTXQ Textarea request paramater
by brian＠kennison.name 27 Feb '25

27 Feb '25

Everyone, I’m trying to build a comment form using RESTXQ that has a texarea element. I was hoping to use the new lines from the textarea for simple formatting but when the form is submitted the request parameter is striped of all the linefeeds ( it looks like normalized text). Is this the expected behavior? Thanks — Brian

3 4

Editor format adjustments
by Joel Kalvesmaki 24 Feb '25

24 Feb '25

Hi everyone, I just joined. BaseX is awesome (as y'all know). I like CTRL+SHIFT+F for formatting, but it is also messing up string values, which especially wreaks havoc with regular expressions. That is... let $regex := "(a|z)" ...becomes... let $regex := "( a|z )" I didn't see anything in the documentation or archives about micromanaging the formatting. Is the best practice to avoid formatting altogether? Or is there a hidden pragma to exempt lines from being formatted? Joel -- Joel Kalvesmaki Director, Text Alignment Network http://textalign.net

5 5

Re: Synchronizing access to store
by Andy Bunce 24 Feb '25

24 Feb '25

>so if you call store:get, store:put or store:write in the first process, a second process will not wait until the store operations are completed. In non XQuery contexts a semaphore [1] might be used to ensure that my other threads don't get between a get and put. In the spirit of blurring the XQuery Java boundaries I tried [2]. It seems to work. Is it dangerous? [1] https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Semaphore.ht… [2] declare namespace Semphore ="java:java.util.concurrent.Semaphore"; declare function local:config-update($k as xs:string,$v as item(),$sem) { Semphore:acquire($sem), try{ let $u:=store:get("config")=> map:put($k, $v) return store:put("config",$u) }catch * { trace("Errrr",$err:description) } ,Semphore:release($sem) }; let $sem:=Semphore:new(1,true()) let $s1 := store:put("config", map{}) let $s2 := xquery:fork-join( for $i in (1 to 100) return function(){ let $r:=(prof:sleep(10),$i) return local:config-update( string($i),$r,$sem) } ) return count(map:keys(store:get("config"))) On Tue, 28 Jan 2025 at 14:09, Marco Lettere <m.lettere(a)gmail.com> wrote: > Ok, thanks for the clarification. > > M. > On 28/01/25 15:08, Christian Grün wrote: > > Sorry Christian, do you mean *not* synchronized? >> > With »synchronized«, I meant to refer to a lower level: You will not end > up with a corrupt key/value store or with I/O conflicts when accessing and > updating the store via multiple threads. However, as you have already > observed, multiple operations are not executed in a well-defined order, so > if you call store:get, store:put or store:write in the first process, a > second process will not wait until the store operations are completed. > >

3 5

where instead of when in window start clause
by Martin Honnen 22 Feb '25

22 Feb '25

I mistyped a start clause in a tumbling window expression using "where" instead of "when" for tumbling window $w in (1 to 20) start at $s where $s mod 3 = 1 return <window>{$w}</window> see https://fiddle.basex.org/?share=%28%27query%21%27for+tumbling+-*w+in+%7B1+t…, but I didn't get an error but a result <window>1</window> <window>4</window> <window>7</window> <window>10</window> <window>13</window> <window>16</window> <window>19</window> Shouldn't that query give a syntax error that "when" is expected instead of "where"? Or is that a new XQuery 4 feature that the "when" clause can be omitted and the above is kind of parsed/executed as for tumbling window $w in (1 to 20) start at $s where $s mod 3 = 1 return <window>{$w}</window> ?

2 1

Install on windows fails because of JAVA_TOOL_OPTIONS
by Peter Boot 22 Feb '25

22 Feb '25

Hello, I tried to install BaseX on Windows 11 and it kept giving me the message that Java 11 was needed, even though I already was at 20 and now am at 21. Then I noticed that java --version also reported a JAVA_TOOLS_OPTIONS environment variable: java --version Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 openjdk 21.0.6 2025-01-21 LTS OpenJDK Runtime Environment Temurin-21.0.6+7 (build 21.0.6+7-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.6+7 (build 21.0.6+7-LTS, mixed mode, sharing) After removing that variable it no longer appears in the output of the version command and the install runs fine. I suppose it messes up parsing the version output. Peter

2 1

Need confirmation on http:send-request
by Marco Lettere 13 Feb '25

13 Feb '25

Dear Christian et al, moving to basex 11.7 today I've found out that it is not necessary to serialize the body content in an http-request such as [1]. If I do (as I had to up to Basex 10.7) the body is no longer understood. Now I obtsain correct behaviour when using code as in [2]. Can you confirm this change in behaviour? And if yes, this has a huge impact on the many many http calls we have so maybe it should be documented? Thanks a lot as usual! M. [1] let $body := json:serialize(<json type="object"/>) return <http:request href="url" method="POST"> <http:body media-type="application/json">{$body}</http:body> </http:request> [2] let $body := <json type="object"/> return <http:request href="url" method="POST"> <http:body media-type="application/json">{$body}</http:body> </http:request>

2 1

None
by None 28 Jan '25

28 Jan '25

people (there is some reason why no other XQuery processor chose this solution =96 and why so many mailing list entries from implementations other than BaseX focus so much an namespaces..). Some more introductory details on various namespace intricacies, and the discussion around it, are e.g. found at: http://www.jclark.com/xml/xmlns.htm http://www.stylusstudio.com/xmldev/201004/bythread.html Christian

1 0

None
by None 28 Jan '25

28 Jan '25

dropped and synthetically generated during the serialization process; and that our implementation would look much cleaner.

1 0

None
by None 28 Jan '25

28 Jan '25

BaseX's behavior is somehow influenced by whether a document uses namespaces or not? Is that true? In other words, BaseX shows different performance depending on whether prefixes are used? Why is that so? Why did you not choose a representation that abstracts away namespace prefixes and treats all elements as if they were in a namespace? Logically, it's not a higher burden (storing a pair (index, string) is just as efficient as storing or indexing a string); and BaseX is not required to output XML that preserves prefixes and default namespaces when a query is made; any equivalent XML that expresses the query result is acceptable. I'm wondering if the correctness problems we're seeing with respect to namespaces may be due to this decision of treating namespaces specially rather than the default case. - Godmar

1 0

None
by None 28 Jan '25

28 Jan '25

parameter applies only where wrap=3Dyes (it is ignored when wrap=3Dno) output does allow media-type to be specified...interestingly, the spec you refer to says the media-type can contain a value in line with RFC2046, that RFC happens to include textual media-types as well (e.g., text/plain) as XM= L media-types. So, I would propose to use a) the situation as it is today (wrap=3Dno, wrap=3Dyes dictating whether jax-rx:result and jax-rx:results are used to wrap) but also b) to be able to override the media-type independently of wrap parameter's value using output=3Dmedia-type=3Dtext%2Fplain or output=3Dmedia-type=3Dapplication%2fxml for example. Whether to use text/p= lain for wrap=3Dno becomes non-critical then (because of the ability to override it) and leaving it at text/plain as default is probably fine. Thanks. On Mon, Jan 31, 2011 at 11:01 AM, Christian Gr=FCn <christian.gruen(a)gmail.com>wrote: > > Okay, I thought setting output to application/xml but wrap=3Dno will me= an > the > > person writing the query is taking the responsibility that they do not > want > > results to be wrapped but know the result is xml so forcing the output = to > be > > application/xml (so that the response mime-type is set to application/x= ml > in > > this case)...what are the valid values for output parameter? > > All parameters are defined in the W3 specs: > http://www.w3.org/TR/xslt-xquery-serialization/ > > Please browse our JAX-RX docs for some usage examples: > http://docs.basex.org/wiki/JAX-RX_API > > > An invocation like > > http://localhost:8984/basex/jax-rx?wrap=3Dno&query=3D1+to+10&output=3Dt= ext/xmlor > > > http://localhost:8984/basex/jax-rx?wrap=3Dyes&query=3D1+to+10&output=3Dte= xt/xml > > (or text%2Fxml) results in: > > Yes, I see that there's some need to work on the response media type. > I have two solutions in mind: > > a) All textual results of "query" and "run" could be returned as > application/xml, no matter what value has been assigned to "wrap". > This would mean that all non-XML query results (e.g., resulting from a > XQuery like "1 to 10") would be handles as XML, too. > > b) This is one is similar to your approach: an additional JAX-RX > parameter could be introduced to explicitly overwrite the resulting > media type. Example: > > http://localhost:8984/basex/jax-rx?wrap=3Dyes&query=3D1&media=3Dapplicat= ion/xml > > What do you, and others, think? > > Both changes are not BaseX-centric, but have to be made in the JAX-RX > interface, so this might take some more time; but I'll definitely add > this to our internal issue tracker. > > Christian > --0016e64c2a1a56ee16049b22f778 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The scope of this posting is only xquery. From your discussion on ou= tput parameter, it appears to me that that parameter applies only where wra= p=3Dyes (it is ignored when wrap=3Dno) output does allow media-type = to be specified...interestingly, the spec you refer to says the media-type = can contain a value in line with RFC2046, that RFC happens to include textu= al media-types as well (e.g., text/plain) as XML media-types. So, I would propose to use a) the situation as it is today (wrap=3Dno, wrap= =3Dyes dictating whether jax-rx:result and jax-rx:results are used to wrap)= but also b) to be able to override the media-type independently of wrap pa= rameter's value using output=3Dmedia-type=3Dtext%2Fplain or output=3Dme= dia-type=3Dapplication%2fxml for example.=A0 Whether to use text/plain for = wrap=3Dno becomes non-critical then (because of the ability to override it)= and leaving it at text/plain as default is probably fine. Thanks. <div class=3D"gmail_quote">On Mon, Jan 31, 2011 = at 11:01 AM, Christian Gr=FCn <<a href=3D"mailto:chris= tian.gruen(a)gmail.com">christian.gruen(a)gmail.com</a>> wrote: <b= lockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-= left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class=3D"im">> Okay, I thought setting output to application/xml bu= t wrap=3Dno will mean the > person writing the query is taking the responsibility that they do not= want > results to be wrapped but know the result is xml so forcing the output= to be > application/xml (so that the response mime-type is set to application/= xml in > this case)...what are the valid values for output parameter? </div>All parameters are defined in the W3 specs: =A0<a href=3D"http://www.w3.org/TR/xslt-xquery-serialization/" target=3D"_= blank">http://www.w3.org/TR/xslt-xquery-serialization/</a> Please browse our JAX-RX docs for some usage examples: =A0<a href=3D"http://docs.basex.org/wiki/JAX-RX_API" target=3D"_blank">htt= p://docs.basex.org/wiki/JAX-RX_API</a> <div class=3D"im"> > An invocation like > <a href=3D"http://localhost:8984/basex/jax-rx?wrap=3Dno&query=3D1+= to+10&output=3Dtext/xml" target=3D"_blank">http://localhost:8984/basex/= jax-rx?wrap=3Dno&query=3D1+to+10&output=3Dtext/xml</a> or > <a href=3D"http://localhost:8984/basex/jax-rx?wrap=3Dyes&query=3D1= +to+10&output=3Dtext/xml" target=3D"_blank">http://localhost:8984/basex= /jax-rx?wrap=3Dyes&query=3D1+to+10&output=3Dtext/xml</a> > (or text%2Fxml) results in: </div>Yes, I see that there's some need to work on the response media t= ype. I have two solutions in mind: a) All textual results of "query" and "run" could be re= turned as application/xml, no matter what value has been assigned to "wrap"= . This would mean that all non-XML query results (e.g., resulting from a XQuery like "1 to 10") would be handles as XML, too. b) This is one is similar to your approach: an additional JAX-RX parameter could be introduced to explicitly overwrite the resulting media type. Example: =A0<a href=3D"http://localhost:8984/basex/jax-rx?wrap=3Dyes&query=3D1&= amp;media=3Dapplication/xml" target=3D"_blank">http://localhost:8984/basex/= jax-rx?wrap=3Dyes&query=3D1&media=3Dapplication/xml</a> What do you, and others, think? Both changes are not BaseX-centric, but have to be made in the JAX-RX interface, so this might take some more time; but I'll definitely add<b= r> this to our internal issue tracker. Christian </blockquote></div> --0016e64c2a1a56ee16049b22f778--

1 0