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