Re: [basex-talk] DBA Editor behavior in v11 not as expected

[Christian Grün]

…thanks; we’ve added some usability tweaks in the editor.


On Mon, Mar 4, 2024 at 11:15 AM Eliot Kimber 
wrote:

> Now that I’m using an expected extension, a bit more feedback on the
> Editor UI.
>
>
>
> Having saved a file and then not modified what’s in the editor, opening a
> new file should not prompt for confirmation as the editor isn’t “dirty” and
> there can be no data loss (the contents of the editor were just saved).
>
>
>
> In my case I’m switching between two little test scripts: one to store
> docs and one to operate on them, so having to respond to an unnecessary
> confirmation every time I switch is annoying.
>
>
>
> Cheers,
>
>
>
> E.
>
> _
>
> *Eliot Kimber*
>
> Sr Staff Content Engineer
>
> O: 512 554 9368
>
> M: 512 554 9368
>
> servicenow.com 
>
> LinkedIn  | Twitter
>  | YouTube
>  | Facebook
> 
>
>
>
> *From: *Christian Grün 
> *Date: *Friday, March 1, 2024 at 2:58 PM
> *To: *Eliot Kimber 
> *Cc: *BaseX 
> *Subject: *Re: [basex-talk] DBA Editor behavior in v11 not as expected
> *[External Email]*
>
>
> --
>
> Good to know, it'll be easy to fix that [1]; we should do so anyway [2].
>
>
>
> [1]
> https://github.com/BaseXdb/basex/blob/main/basex-api/src/main/webapp/dba/static/editor.js#L56
>
> [2] https://help.basex.org/main/XQuery_Extensions#suffixes
>
>
>
> Eliot Kimber  schrieb am Fr., 1. März 2024,
> 21:41:
>
> I use “.xqy” for full XQuery scripts and “.xqm” for XQuery modules.
>
>
>
> Cheers,
>
>
>
> E.
>
>
>
> _
>
> *Eliot Kimber*
>
> Sr Staff Content Engineer
>
> O: 512 554 9368
>
> M: 512 554 9368
>
> servicenow.com 
>
> LinkedIn  | Twitter
>  | YouTube
>  | Facebook
> 
>
>
>
> *From: *Christian Grün 
> *Date: *Friday, March 1, 2024 at 10:57 AM
> *To: *Eliot Kimber 
> *Cc: *BaseX 
> *Subject: *Re: [basex-talk] DBA Editor behavior in v11 not as expected
> *[External Email]*
>
>
> --
>
> Hi Eliot,
>
>
>
> We have aligned the behavior of the DBA editor to the BaseX GUI. Saved
> files are only executable if they are detected as XQuery file.
>
>
>
> But maybe we need to support some more file suffixes (.xq is the default
> extension). How do you name your files?
>
>
>
> Best,
>
> Christian
>
>
>
>
>
> Eliot Kimber  schrieb am Fr., 1. März 2024,
> 17:52:
>
> Using the 27-02-2024 build of v11, if I create a query in the Editor panel
> and then save it, the Run button is disabled, which is unexpected.
>
>
>
> If I then open the file, the Run button remains disabled.
>
>
>
> If I cut the contents of the editing panel, select “close” to clear the
> panel, then paste back into the panel, the Run button is enabled.
>
>
>
> I think this behavior is incorrect—as long as there is some content in the
> editor the Run button should be enabled.
>
>
>
> Cheers,
>
>
>
> E.
>
>
>
> _
>
> *Eliot Kimber*
>
> Sr Staff Content Engineer
>
> O: 512 554 9368
>
> M: 512 554 9368
>
> servicenow.com 
>
> LinkedIn  | Twitter
>  | YouTube
>  | Facebook
> 
>
>

Re: [basex-talk] Inconsistency in base-uri()

[Eliot Kimber]

Oh right—I submitted that issue 9 years ago !

Any solution will be challenging due to the age of the current behavior and the 
twisty nature of the code.

My use of @xml:base may be somewhat singular as it’s specific to the way that 
DITA works and I don’t know that there is any other XML document type in common 
usuage that has a similar hyperlink structure that depends on using xml:base.

Cheers,

E.

_
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
servicenow.com
LinkedIn | 
Twitter | 
YouTube | 
Facebook

From: Christian Grün 
Date: Monday, March 4, 2024 at 5:16 AM
To: Eliot Kimber 
Cc: basex-talk@mailman.uni-konstanz.de 
Subject: Re: [basex-talk] Inconsistency in base-uri()
[External Email]


…just a quick reply: That’s probably related to [1], an ancient issue, in which 
I tended to recommend the usage of db:path. I wish we’d finally find time and 
ressources to tackle this.[1] https://github.com/BaseXdb/basex/issues/1172On 
Mon, Mar 4, 2024 at 11:49 AM Eliot Kimber < ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌

i
This message needs your attention
• Someone new is on this email.
Provided by ServiceNow DT (Employee Portal KB0077950) - This banner is visible 
only to ServiceNow employees.
…just a quick reply: That’s probably related to [1], an ancient issue, in which 
I tended to recommend the usage of db:path. I wish we’d finally find time and 
ressources to tackle this.


[1] https://github.com/BaseXdb/basex/issues/1172

On Mon, Mar 4, 2024 at 11:49 AM Eliot Kimber 
mailto:eliot.kim...@servicenow.com>> wrote:
Using BaseX 11 (but I think the code is the same in BaseX 10).

I’m trying to understand how base-uri() behaves relative to how it should 
behave when the database path of a document is not a valid URI, i.e., it has a 
space in it.

First I have this test:

let $doc as document-node() := document { child }
return $doc/*/child ! base-uri(.)

Which produces:

file:///data/basex/data/.dba/temp/child-uri%20with%20space.xml

Which is the correct result: it’s the value of @xml:base and the escaped spaces 
make it a valid URI.

Replacing %20 with “ “ in the @xml:base value results in this error:

 Invalid URI: Illegal character in path at index 14: temp/child-uri with 
space.xml.

Also correct as the spaces have to be escaped.

This verifies that base-uri() applied to nodes with explicit @xml:base 
attributes work per the spec. But this test does not involve database paths.

To try to test things with database paths I then created this pair of test 
scripts:

Script to put docs in a database:

let $db := 'temp'
let $filename as xs:string := 'with space.xml'
let $doc1 as document-node() := document {No 
xml:base}
let $doc2 as document-node() := document { Wi

Re: [basex-talk] Inconsistency in base-uri()

[Christian Grün]

…just a quick reply: That’s probably related to [1], an ancient issue, in
which I tended to recommend the usage of db:path. I wish we’d finally find
time and ressources to tackle this.


[1] https://github.com/BaseXdb/basex/issues/1172

On Mon, Mar 4, 2024 at 11:49 AM Eliot Kimber 
wrote:

> Using BaseX 11 (but I think the code is the same in BaseX 10).
>
>
>
> I’m trying to understand how base-uri() behaves relative to how it should
> behave when the database path of a document is not a valid URI, i.e., it
> has a space in it.
>
>
>
> First I have this test:
>
>
>
> let $doc as document-node() := document {  xml:base="temp/child-uri%20with%20space.xml">child }
>
> return $doc/*/child ! base-uri(.)
>
>
>
> Which produces:
>
> file:///data/basex/data/.dba/temp/child-uri%20with%20space.xml
>
>
>
> Which is the correct result: it’s the value of @xml:base and the escaped
> spaces make it a valid URI.
>
>
>
> Replacing %20 with “ “ in the @xml:base value results in this error:
>
> * Invalid URI: Illegal character in path at index 14: temp/child-uri with
> space.xml.*
>
>
>
> Also correct as the spaces have to be escaped.
>
>
>
> This verifies that base-uri() applied to nodes with explicit @xml:base
> attributes work per the spec. But this test does not involve database paths.
>
>
>
> To try to test things with database paths I then created this pair of test
> scripts:
>
> Script to put docs in a database:
>
> let $db := 'temp'
>
> let $filename as xs:string := 'with space.xml'
>
> let $doc1 as document-node() := document {No
> xml:base}
>
> let $doc2 as document-node() := document {  xml:base="{'/temp/xmlbase/doc2_' || $filename}">With xml:base
> unescaped }
>
> let $doc3 as document-node() := document {  xml:base="{iri-to-uri( '/temp/xmlbase/doc3_' || $filename)}">With xml:base
> escaped }
>
> return (()
>
> ,db:put($db, $doc1, 'doc1_' || $filename)
>
> ,db:put($db, $doc2, 'doc2_' || $filename)
>
> ,db:put($db, $doc3, 'doc3_' || $filename)
>
> )
>
>
>
> Script to report on them:
>
> let $db := 'temp'
>
> let $filenameBase as xs:string := 'with space.xml'
>
> return
>
> for $i in 1 to 3
>
>   let $filename := 'doc' || $i  || '_' || $filenameBase
>
>   let $doc := db:get($db, $filename)
>
>   let $child as element() := $doc/*/child
>
>   let $dbPath := db:path($doc)
>
>   let $baseUriDoc := base-uri($doc)
>
>   let $baseUriChild :=
>
>   try {
>
> base-uri($child)
>
>   } catch * {
>
> $err:description
>
>   }
>
>   return (()
>
>,``[
>
> Doc "`{$dbPath}`":]``
>
>,$doc
>
>,``[xml:base att:  "`{$child/@xml:base}`"]``
>
>,``[base URI of doc:  "`{$baseUriDoc}`"]``
>
>,``[base URI of child: "`{$baseUriChild}`"]``
>
>   )
>
>
>
> Which returns this result:
>
> Doc "doc1_with space.xml":
>
> 
>
>   No xml:base
>
> 
>
> xml:base att:  ""
>
> base URI of doc:  "/temp/doc1_with space.xml"
>
> base URI of child: "/temp/doc1_with space.xml"
>
>
>
> Doc "doc2_with space.xml":
>
> 
>
>   With xml:base
> unescaped
>
> 
>
> xml:base att:  "/temp/xmlbase/doc2_with space.xml"
>
> base URI of doc:  "/temp/doc2_with space.xml"
>
> base URI of child: "Invalid URI: Illegal character in path at index 23:
> /temp/xmlbase/doc2_with space.xml."
>
>
>
> Doc "doc3_with space.xml":
>
> 
>
>   With xml:base
> escaped
>
> 
>
> xml:base att:  "/temp/xmlbase/doc3_with%20space.xml"
>
> base URI of doc:  "/temp/doc3_with space.xml"
>
> base URI of child: "Invalid URI: Illegal character in path at index 15:
> /temp/doc3_with space.xml."
>
>
>
> Note the result for doc3: It’s reporting the base URI of the document
> (/temp/doc3_with space.xml), not the base URI of the child
> (/temp/xmlbase/doc_with%20space.xml). Why? I think the answer is that under
> the covers it’s doing resolve-uri(), which also checks the validity of both
> the base and relative parts.
>
>
>
> One observation is that base-uri() is treating the db-provided base URI
> differently from an xml:base-provided base URI, but only when there is no
> @xml:base attribute.
>
>
>
> In doc 1, the database path has a space but base-uri() does not fail when
> returning it even though it’s not a valid URI. Why not?
>
>
>
> In doc 2, the xml:base-supplied base URI is correctly reported as invalid,
> but the database-supplied base URI of the root is not reported as invalid.
>
>
>
> My expectation would be that the behavior is consistent: Either all URIs
> must be valid, including those coming from database paths or all are
> automatically escaped (as though iri-to-uri() had been applied).
>
>
>
> Finally, why do I get the result for doc 3, where it’s reporting the
> database path as the base URI of the child rather than the
> @xml:base-defined base URI (which is correctly escaped).
>
>
>
> In my code, which depends on the use of @xml:base to do DITA link
> resolution for “resolved” DITA maps, I’ve adjusted my code to escape URIs
> in @xml:base values and as far as I can tell everything works as it should.
> But I’m still concerned about the incons

[basex-talk] Inconsistency in base-uri()

[Eliot Kimber]

Using BaseX 11 (but I think the code is the same in BaseX 10).

I’m trying to understand how base-uri() behaves relative to how it should 
behave when the database path of a document is not a valid URI, i.e., it has a 
space in it.

First I have this test:

let $doc as document-node() := document { child }
return $doc/*/child ! base-uri(.)

Which produces:

file:///data/basex/data/.dba/temp/child-uri%20with%20space.xml

Which is the correct result: it’s the value of @xml:base and the escaped spaces 
make it a valid URI.

Replacing %20 with “ “ in the @xml:base value results in this error:

 Invalid URI: Illegal character in path at index 14: temp/child-uri with 
space.xml.

Also correct as the spaces have to be escaped.

This verifies that base-uri() applied to nodes with explicit @xml:base 
attributes work per the spec. But this test does not involve database paths.

To try to test things with database paths I then created this pair of test 
scripts:

Script to put docs in a database:

let $db := 'temp'
let $filename as xs:string := 'with space.xml'
let $doc1 as document-node() := document {No 
xml:base}
let $doc2 as document-node() := document { With xml:base 
unescaped }
let $doc3 as document-node() := document { With xml:base escaped }
return (()
,db:put($db, $doc1, 'doc1_' || $filename)
,db:put($db, $doc2, 'doc2_' || $filename)
,db:put($db, $doc3, 'doc3_' || $filename)
)

Script to report on them:

let $db := 'temp'
let $filenameBase as xs:string := 'with space.xml'
return
for $i in 1 to 3
  let $filename := 'doc' || $i  || '_' || $filenameBase
  let $doc := db:get($db, $filename)
  let $child as element() := $doc/*/child
  let $dbPath := db:path($doc)
  let $baseUriDoc := base-uri($doc)
  let $baseUriChild :=
  try {
base-uri($child)
  } catch * {
$err:description
  }
  return (()
   ,``[
Doc "`{$dbPath}`":]``
   ,$doc
   ,``[xml:base att:  "`{$child/@xml:base}`"]``
   ,``[base URI of doc:  "`{$baseUriDoc}`"]``
   ,``[base URI of child: "`{$baseUriChild}`"]``
  )

Which returns this result:

Doc "doc1_with space.xml":

  No xml:base

xml:base att:  ""
base URI of doc:  "/temp/doc1_with space.xml"
base URI of child: "/temp/doc1_with space.xml"

Doc "doc2_with space.xml":

  With xml:base 
unescaped

xml:base att:  "/temp/xmlbase/doc2_with space.xml"
base URI of doc:  "/temp/doc2_with space.xml"
base URI of child: "Invalid URI: Illegal character in path at index 23: 
/temp/xmlbase/doc2_with space.xml."

Doc "doc3_with space.xml":

  With xml:base 
escaped

xml:base att:  "/temp/xmlbase/doc3_with%20space.xml"
base URI of doc:  "/temp/doc3_with space.xml"
base URI of child: "Invalid URI: Illegal character in path at index 15: 
/temp/doc3_with space.xml."

Note the result for doc3: It’s reporting the base URI of the document 
(/temp/doc3_with space.xml), not the base URI of the child 
(/temp/xmlbase/doc_with%20space.xml). Why? I think the answer is that under the 
covers it’s doing resolve-uri(), which also checks the validity of both the 
base and relative parts.

One observation is that base-uri() is treating the db-provided base URI 
differently from an xml:base-provided base URI, but only when there is no 
@xml:base attribute.

In doc 1, the database path has a space but base-uri() does not fail when 
returning it even though it’s not a valid URI. Why not?

In doc 2, the xml:base-supplied base URI is correctly reported as invalid, but 
the database-supplied base URI of the root is not reported as invalid.

My expectation would be that the behavior is consistent: Either all URIs must 
be valid, including those coming from database paths or all are automatically 
escaped (as though iri-to-uri() had been applied).

Finally, why do I get the result for doc 3, where it’s reporting the database 
path as the base URI of the child rather than the @xml:base-defined base URI 
(which is correctly escaped).

In my code, which depends on the use of @xml:base to do DITA link resolution 
for “resolved” DITA maps, I’ve adjusted my code to escape URIs in @xml:base 
values and as far as I can tell everything works as it should. But I’m still 
concerned about the inconsistency in the behavior of base-uri().

I tried to trace through the code that handles base-uri() but it’s pretty 
twisty and does different things for files and nodes.

It would obviously be very disruptive to have base-uri() start failing on 
database paths with spaces—I think the current behavior dates back to the very 
start of BaseX, but it’s still an inconsistency that can lead to trouble with 
the unawares.

For example, consider this code:

let $topicref := db:get('maps', 'map with space.ditamap')/*/topicref[@href][1]
let $target as element()? := local:resolve-href($topicref)
let $baseUri as xs:string := base-uri($target) ! string(.)
let $newElem as element := 
return base-uri($newElem)

The value of $baseUri will be “map with space.ditamap”, not 
“map%20with%20space.ditamap”, making the value of @xml:base on $newElem: 

Re: [basex-talk] DBA Editor behavior in v11 not as expected

[Eliot Kimber]

Now that I’m using an expected extension, a bit more feedback on the Editor UI.

Having saved a file and then not modified what’s in the editor, opening a new 
file should not prompt for confirmation as the editor isn’t “dirty” and there 
can be no data loss (the contents of the editor were just saved).

In my case I’m switching between two little test scripts: one to store docs and 
one to operate on them, so having to respond to an unnecessary confirmation 
every time I switch is annoying.

Cheers,

E.
_
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
servicenow.com
LinkedIn | 
Twitter | 
YouTube | 
Facebook

From: Christian Grün 
Date: Friday, March 1, 2024 at 2:58 PM
To: Eliot Kimber 
Cc: BaseX 
Subject: Re: [basex-talk] DBA Editor behavior in v11 not as expected
[External Email]


Good to know, it'll be easy to fix that [1]; we should do so anyway [2].

[1] 
https://github.com/BaseXdb/basex/blob/main/basex-api/src/main/webapp/dba/static/editor.js#L56
[2] 
https://help.basex.org/main/XQuery_Extensions#suffixes

Eliot Kimber mailto:eliot.kim...@servicenow.com>> 
schrieb am Fr., 1. März 2024, 21:41:
I use “.xqy” for full XQuery scripts and “.xqm” for XQuery modules.

Cheers,

E.

_
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
servicenow.com
LinkedIn | 
Twitter | 
YouTube | 
Facebook

From: Christian Grün 
mailto:christian.gr...@gmail.com>>
Date: Friday, March 1, 2024 at 10:57 AM
To: Eliot Kimber 
mailto:eliot.kim...@servicenow.com>>
Cc: BaseX 
mailto:basex-talk@mailman.uni-konstanz.de>>
Subject: Re: [basex-talk] DBA Editor behavior in v11 not as expected
[External Email]


Hi Eliot,

We have aligned the behavior of the DBA editor to the BaseX GUI. Saved files 
are only executable if they are detected as XQuery file.

But maybe we need to support some more file suffixes (.xq is the default 
extension). How do you name your files?

Best,
Christian


Eliot Kimber mailto:eliot.kim...@servicenow.com>> 
schrieb am Fr., 1. März 2024, 17:52:
Using the 27-02-2024 build of v11, if I create a query in the Editor panel and 
then save it, the Run button is disabled, which is unexpected.

If I then open the file, the Run button remains disabled.

If I cut the contents of the editing panel, select “close” to clear the panel, 
then paste back into the panel, the Run button is enabled.

I think this behavior is incorrect—as long as there is some content in the 
editor the Run button should be enabled.

Cheers,

E.

_
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
servicenow.com
LinkedIn | 
Twitter | 
YouTube | 
Facebook

Re: [basex-talk] Optimize database never returns, leaves database in "opened by another process" state

[Eliot Kimber]

As reported in a separate thread, I’m still getting the optimization failure 
for large databases but not smaller ones. This behavior is consistent in my 
tests.

Cheers,

E.

_
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
servicenow.com
LinkedIn | 
Twitter | 
YouTube | 
Facebook

From: Christian Grün 
Date: Friday, March 1, 2024 at 9:30 AM
To: Eliot Kimber 
Cc: BaseX 
Subject: Re: [basex-talk] Optimize database never returns, leaves database in 
"opened by another process" state
[External Email]


Glad to hear it, thanks Eliot.

Eliot Kimber mailto:eliot.kim...@servicenow.com>> 
schrieb am Fr., 1. März 2024, 16:21:
Using the 27-02-2024 build I have confirmed that the optimize database deadlock 
seems to be resolved.

I was able to easily upgrade my code to replace prof:dump() with message() and 
db:open() with db:get() and everything else seems to be working as it should.

I like the new Editor replacement for the old Query feature in the DBA app.

Cheers,

E.

_
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
servicenow.com
LinkedIn | 
Twitter | 
YouTube | 
Facebook

From: Christian Grün 
mailto:christian.gr...@gmail.com>>
Date: Wednesday, February 28, 2024 at 9:36 AM
To: Eliot Kimber 
mailto:eliot.kim...@servicenow.com>>
Cc: 
basex-talk@mailman.uni-konstanz.de 
mailto:basex-talk@mailman.uni-konstanz.de>>
Subject: Re: [basex-talk] Optimize database never returns, leaves database in 
"opened by another process" state
[External Email]


…this one could be related to a bug that was recently fixed in the latest 
snapshot [1]. About time to get BaseX 11 finished…

[1] 
https://github.com/BaseXdb/basex/commit/45d97f8065615fb734b712bc4c77c39899e9d496



On Mon, Feb 26, 2024 at 5:25 PM Eliot Kimber 
mailto:eliot.kim...@servicenow.com>> wrote:
Using Basex 10.7 on Linux.

I’m running a sequence of jobs to update and optimize a set of databases 
following loading a number of documents created dynamically (as opposed to 
being read from disk).

I’m seeing a new behavior, which is that the optimization step never completes 
but also doesn’t show any error in the log. The database shows no items and is 
in the locked by another process state if I try to drop it. This behavior seems 
to be consistently repeatable with my current code base (I’m working on some 
code updates, so it’s possible I’ve introduced something that would cause this 
behavior but I haven’t changed the code that leads up to the failing optimize). 
The server has plenty of disk space, etc.

Optimization code is:

   try {
 if (db:exists($database))
 then
 (
   util:logToConsole('dbadmin:optimizeDatabase', ``[Optimizing database 
`{$database}`]``),
   db:optimize($database, true(), $dbadmin:dbOptimizeOptions)
 )
 else util:logToConsole('dbadmin:optimizeDatabase', ``[Database 
'`{$database}`' does not exist. Nothing to optimize.]``)
   } catch * {
 util:logToConsole(
   'dbadmin:optimizeDatabase',
   ``[Exception optimizing database '`{$database}`': `{$err:code}` - 
`{$err:description}`]``,
   'error')
   }

And the optimization options are:

declare variable $dbadmin:dbOptimizeOptions as map(*) :=
(: Turn on all the indexes :)
  map {
'attrindex' : true(),
'tokenindex' : true(),
'textindex' : true(),
'ftindex' : true()
  };

This code has been working fine for a long time and I’ve been running 10.7 for 
a least a couple of months, so I’m wondering:

A) Would would cause this behavior?
B) How can I diagnose it short of debugging the Java code (which I can do but 
it’s non-trivial for me to set up).

Thanks,

Eliot

_
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
servicenow.com
LinkedIn | 
Twitter | 
YouTube | 
Facebook