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