Hi,
given the following RESTXQ function: declare %rest:path("/myrest/{$db}") %rest:GET %output:method("xhtml") %output:omit-xml-declaration("no") %output:doctype-public("-//W3C//DTD XHTML 1.0 Transitional//EN") %output:doctype-system("http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd") function page:html($db as xs:string) { <html xmlns="http://www.w3.org/1999/xhtml"> <body> Database creation date: {db:info("NB")/databaseproperties/timestamp/text()}<br/> </body> </html> };
The website returns "Database creation date: " (without a timestamp)
If I put that into a function: declare function page:getDBTimestamp($db as xs:string) { db:info($db)/databaseproperties/timestamp/text() };
and call it in the page: <body> Database creation date: {page:getDBTimestamp($db)}<br/> </body>
then I can see the timestamp.
Can somebody explain to my why it makes a difference and why I cannot query the database directly from the RESTXQ function?
Alex
Hi Alex,
You’ve stumbled upon a hidden XQuery feature: If you declare a default namespace in a node constructor…
<html xmlns="http://www.w3.org/1999/xhtml">
…and if you perform a path expression somewhere within that constructor, the default namespace in that scope will be applied to your path. You can circumvent this by either moving the path expression outside the constructor…
let $ts := db:info($db)//timestamp/text() return <html xmlns="http://www.w3.org/1999/xhtml"> <body> Database creation date: { $ts }<br/> </body> </html>
…or by overwriting the default namespace:
Database creation date: { db:info($db)//Q{}timestamp/text() }<br/>
Hope this helps, Christian
On Mon, Mar 27, 2023 at 3:42 PM Alexander Krasnogolowy alexkrasno@hotmail.com wrote:
Hi,
given the following RESTXQ function: declare %rest:path("/myrest/{$db}") %rest:GET %output:method("xhtml") %output:omit-xml-declaration("no") %output:doctype-public("-//W3C//DTD XHTML 1.0 Transitional//EN") %output:doctype-system("http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd") function page:html($db as xs:string) {
<html xmlns="http://www.w3.org/1999/xhtml"> <body> Database creation date: {db:info("NB")/databaseproperties/timestamp/text()}<br/> </body> </html> };
The website returns "Database creation date: " (without a timestamp)
If I put that into a function: declare function page:getDBTimestamp($db as xs:string) { db:info($db)/databaseproperties/timestamp/text() };
and call it in the page: <body> Database creation date: {page:getDBTimestamp($db)}<br/> </body>
then I can see the timestamp.
Can somebody explain to my why it makes a difference and why I cannot query the database directly from the RESTXQ function?
Alex
Is that a BaseX-specific feature?
I’d say it’s more the rule than the exception that the namespaces of the source and target documents differ, so making the declared default namespace on a direct element constructor the default element namespace for expressions inside isn’t that helpful.
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.
Shouldn’t computed element constructors and direct element constructors be equivalent?
Gerrit
On 27.03.2023 15:54, Christian Grün wrote:
Hi Alex,
You’ve stumbled upon a hidden XQuery feature: If you declare a default namespace in a node constructor…
<html xmlns="http://www.w3.org/1999/xhtml">
…and if you perform a path expression somewhere within that constructor, the default namespace in that scope will be applied to your path. You can circumvent this by either moving the path expression outside the constructor…
let $ts := db:info($db)//timestamp/text() return <html xmlns="http://www.w3.org/1999/xhtml"> <body> Database creation date: { $ts }<br/> </body>
</html>
…or by overwriting the default namespace:
Database creation date: { db:info($db)//Q{}timestamp/text() }<br/>Hope this helps, Christian
On Mon, Mar 27, 2023 at 3:42 PM Alexander Krasnogolowy alexkrasno@hotmail.com wrote:
Hi,
given the following RESTXQ function: declare %rest:path("/myrest/{$db}") %rest:GET %output:method("xhtml") %output:omit-xml-declaration("no") %output:doctype-public("-//W3C//DTD XHTML 1.0 Transitional//EN") %output:doctype-system("http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd") function page:html($db as xs:string) {
<html xmlns="http://www.w3.org/1999/xhtml"> <body> Database creation date: {db:info("NB")/databaseproperties/timestamp/text()}<br/> </body> </html> };
The website returns "Database creation date: " (without a timestamp)
If I put that into a function: declare function page:getDBTimestamp($db as xs:string) { db:info($db)/databaseproperties/timestamp/text() };
and call it in the page: <body> Database creation date: {page:getDBTimestamp($db)}<br/> </body>
then I can see the timestamp.
Can somebody explain to my why it makes a difference and why I cannot query the database directly from the RESTXQ function?
Alex
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/
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/
I found a matching issue on the qtspecs repo and added a comment that at least the rules be stated more explicitly: https://github.com/qt4cg/qtspecs/issues/65#issuecomment-1486293852
The sentence that Christian cited as [1] is now in a note, but it isn’t any clearer: https://qt4cg.org/specifications/xquery-40/xquery-40.html#id-element-constru...
Gerrit
On 27.03.2023 16:53, Imsieke, Gerrit, le-tex wrote:
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/
Dear BaseX Talk Folks, Naval Sarda of EpiComm Technologies is developing a StratML-enable query service for me, running on BaseX. I invite you to check out the initial iteration at https://search.aboutthem.info/%C2%A0and give us your feedback. For additional background, see https://aboutthem.info/%C2%A0&%C2%A0https://connectedcommunity.net/ BTW, one of the issues we've encountered with respect to the full-text query capability is the lack of recognition of spaces. For example, a query for "Stand Together" turns up 14 hits but this one is a false positive due to the occurrence of these words: "understand together". In that instance, the problem occurs due to failure to treat "stand" as a separate word, but in others, the full-text query capability mashes together words with spaces between them and treats them as a continuous string of characters. I'll look forward to learning if something can be done about that issue to reduce the incidence of false positives. Naval, a "BaseX" query turns up several hits, including this one, which reminds me that Peter Winstanley created a GitHub repository referencing StratML search capabilities. As you know, I want to open source the code and invite others to reuse, extend, and enhance it. What I care about is not ownership but, rather, capitalizing on the potential expressed in the vision of the StratML standard (ISO 17469-1):
A worldwide web of intentions, stakeholders, and results
I want to do whatever I can to advance that cause, in partnership with anyone who may embrace it. Owen Amburhttps://www.linkedin.com/in/owenambur/
basex-talk@mailman.uni-konstanz.de
-
Alexander Krasnogolowy -
Christian Grün -
Imsieke, Gerrit, le-tex -
Owen Ambur