Hi Andreas, Thanks for the reproducible test case; a new snapshot with the bug fix is available [1,2]. Have fun, Christian [1] https://files.basex.org/releases/latest/ [2] https://github.com/BaseXdb/basex/commit/2990c9eed30d4a98b74c2f1b36cf06940d5e... On Tue, Jul 4, 2023 at 10:16 AM Andreas Hengsbach | nexoma <andreas.hengsbach@nexoma.de> wrote:

Hello all,

we have probably found a bug, the cause of which is currently unclear to us. Fortunately, the problem is reproducible in a small test case.

Steps to reproduce the problem:

1. import the following XML into a BaseX database "testcase".

### schnipp

<attributes foo="bar">

<attribute name="test1" seq="foo"/>

<attribute name="test2"/>

<attribute name="test3" seq="bar"/>

</attributes>

### schnapp

2. make sure that an attribute index has been created.

3. execute the following script.

### schnipp let $source := db:attribute('testcase', 'bar', 'foo')/..

let $value := (

$source/attribute[@name="test1"]/@seq/data(),

$source/attribute[@name="test2"]/@seq/data(),

$source/attribute[@name="test3"]/@seq/data()

)

return (

$value[2] => inspect:type()

) ### schnapp

Explanation:

The example is really only meant as a test case. For our case we have already found a workaround, so we don't have a serious problem.

The important thing is that the element is read from the database via db:attribute() and then the individual values are combined again into a sequence.

In doing so, we get an untypedAtomic from attribute test1, an empty-sequence() for test2 and an untypedAtomic again for test3.

Observation:

When we read the second value of the sequence by index ($value[2]), we get back an "attribute()" instead of an untypedAtomic.

Expectation:

We would expect an untypedAtomic here again.

Workaround:

We simply used string() instead of data() to explicitly cast the value to a string.

Versions:

We were able to reproduce the problem with 10.4 and the current 10.6. With a very old version 7.9, however, it was not reproducible.

Many thanks and best regards Andreas