If it’s defined in the spec, then it should be Ok.
I read the spec 30 minutes ago, I also read the sentence that you cited, but I didn’t make the connection.
The sentence is quite blurry IMO. Ok, the default element/type namespace may be affected by namespace declaration attributes (including the default namespace declaration attribute). But “may be affected” can mean anything, like the default element/type namespace flinching, blushing or becoming angry.
It should probably say: “The namespace URI of a default namespace declaration attribute in a direct element constructor will become the default element/type namespace for expressions inside the constructor.”
For compatibility reasons it should probably stay the same in XQuery 4.0, but the spec’s prose might need an editorial overhaul at this location.
Gerrit
On 27.03.2023 16:33, Christian Grün wrote:
Hi Gerrit,
Is that a BaseX-specific feature?
That’s actually defined in the spec [1]: “Note that both the statically known namespaces and the default element/type namespace may be affected by namespace declaration attributes found inside the element constructor.”
If I use an element constructor like this:
element Q{http://www.w3.org/1999/xhtml%7Dhtml { <body> Database creation date: {db:info($db)/databaseproperties/timestamp/text()}<br/> </body> }
there is no need to use Q{}timestamp or *:timestamp in the expression.
You are right, the behavior is different if the so-called computed element constructor is used (instead of the direct element constructor).
Shouldn’t computed element constructors and direct element constructors be equivalent?
I agree that the behavior is… challenging. It’s probably too late to get this redefined, but it could still be to get this discussed for XQuery 4 [2].
Best, Christian
[1] https://www.w3.org/TR/xquery-31/#id-element-constructor [2] https://github.com/qt4cg/qtspecs/issues/