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}html {
<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/
