Exist: From eXist 3.6.1 onwards, transform:transform() output of xmlns="" causes err:XQDY0102

Created on 11 Jan 2018  Â·  18Comments  Â·  Source: eXist-db/exist

In eXist 3.6.1, but not in eXist 3.6.0 or any previous versions, when transform:transform() outputs an element with xmlns="" which is embedded within prefixed or default namespace elements this causes the error:

org.xmldb.api.base.XMLDBException: err:XQDY0102 Cannot output a namespace node 
    for the default namespace when the element is in no namespace. 

If the same node sequence is constructed within XQuery it does not cause the error.

I've attached an XQuery which demonstrates the issue.

Finian

xquery version "3.1";
(:
    In eXist-db 3.6.1 this XQuery causes the error

    "org.xmldb.api.base.XMLDBException: err:XQDY0102 Cannot output a namespace node 
    for the default namespace when the element is in no namespace. 
    [at line 28, column 1, source: xquery version "3.1";"

    In eXist-db 3.6.0, this XQuery returns the expected output:

    <package>
        <unprefixed xmlns="http://default-namespace">
            <prefixed:element xmlns:prefixed="http://prefixed-namespace">
                <dummy xmlns=""/>
            </prefixed:element>
        </unprefixed>
    </package

:)
let $xml := <anything/>
let $xslt := 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="#all" version="2.0">
    <xsl:template match="/">
        <unprefixed xmlns="http://default-namespace">
        <prefixed:element xmlns:prefixed="http://prefixed-namespace">
                <dummy xmlns=""/>
            </prefixed:element>
        </unprefixed>
    </xsl:template>
</xsl:stylesheet>

let $output := transform:transform($xml, $xslt, ())

let $package:=
<package>
{$output}
</package>

return $package

test-an-error-in-361.txt

regression

All 18 comments

I actually get a different error (3.7.0-snapshot, almost identical to 3.6.1)

org.xmldb.api.base.XMLDBException: exerr:ERROR org.exist.xquery.XPathException: err:XPST0003 expecting "return", found 'null' [at line 37, column 11]

    at org.exist.xmldb.LocalXPathQueryService.lambda$compile$6(LocalXPathQueryService.java:275)
    at org.exist.xmldb.function.LocalXmldbFunction.apply(LocalXmldbFunction.java:46)
    at org.exist.xmldb.AbstractLocal.withDb(AbstractLocal.java:196)
    at org.exist.xmldb.LocalXPathQueryService.compile(LocalXPathQueryService.java:271)
    at org.exist.client.QueryDialog$QueryThread.run(QueryDialog.java:560)
Caused by: org.exist.xquery.StaticXQueryException: exerr:ERROR org.exist.xquery.XPathException: err:XPST0003 expecting "return", found 'null' [at line 37, column 11]

    at org.exist.xquery.XQuery.compile(XQuery.java:115)
    at org.exist.xquery.XQuery.compile(XQuery.java:79)
    at org.exist.xquery.XQuery.compile(XQuery.java:71)
    at org.exist.xquery.XQuery.compile(XQuery.java:63)
    at org.exist.xmldb.LocalXPathQueryService.compileAndCheck(LocalXPathQueryService.java:299)
    at org.exist.xmldb.LocalXPathQueryService.lambda$compile$6(LocalXPathQueryService.java:272)
    ... 4 more
Caused by: org.exist.xquery.StaticXQueryException: exerr:ERROR org.exist.xquery.XPathException: err:XPST0003 expecting "return", found 'null' [at line 37, column 11]

    at org.exist.xquery.XQuery.compile(XQuery.java:115)
    at org.exist.xquery.XQuery.compile(XQuery.java:79)
    at org.exist.xquery.XQuery.compile(XQuery.java:71)
    at org.exist.xquery.XQuery.compile(XQuery.java:63)
    at org.exist.xmldb.LocalXPathQueryService.compileAndCheck(LocalXPathQueryService.java:299)
    at org.exist.xmldb.LocalXPathQueryService.lambda$compile$6(LocalXPathQueryService.java:272)
    at org.exist.xmldb.function.LocalXmldbFunction.apply(LocalXmldbFunction.java:46)
    at org.exist.xmldb.AbstractLocal.withDb(AbstractLocal.java:196)
    at org.exist.xmldb.LocalXPathQueryService.compile(LocalXPathQueryService.java:271)
    at org.exist.client.QueryDialog$QueryThread.run(QueryDialog.java:560)

let me check.... indeed in the released 3.6.1 I see the error you reported. @adamretter do I need to regenerate files from the antlr code locally? I remember that you did not want to check in generated files... which are checked-in already?

Hi,
Please find another trace throwing the same error moving from 3.6.0 to 3.6.1

err:XQDY0102 Cannot output a namespace node for the default namespace when the element is in no namespace. [at line 492, column 13, source: /exist-data/expathrepo/shared-0.4.2/content/templates.xql]
In function:
    templates:process-surround(node(), node(), xs:string) [498:65:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:process-surround(node(), node(), xs:string) [498:65:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:process-surround(node(), node(), xs:string) [490:47:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:process-surround(node(), node(), xs:string) [463:28:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:surround(node(), map, xs:string, xs:string?, xs:string?, xs:string?) [225:18:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:call-with-args(function, function*, element(), map) [208:13:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:process-output(element(), map, item()*, element()) [205:9:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:call-by-introspection(element(), map, map, function) [187:28:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:call(item(), element(), map) [143:37:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:process(node()*, map) [131:51:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:process(node()*, map) [88:9:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]
    templates:apply(node()+, function, map?, map?) [45:5:/exist-data/expathrepo/shared-0.4.2/content/templates.xql]

This anomaly also occurs in eXist-db 4.0

It's worth adding that the test example models real-world XML constructions in XForms, which is how I came across it in eXist-db 3.6.1, when testing applications that create XForms pages using XSLT, delivered via XQuery:

<html xmlns="http://www.w3.org/1999/xhtml"  xmlns:xf="http://www.w3.org/2002/xforms">

    <head>

        <xf:model id="test-model">

            <xf:instance id="test-instance">
                <test xmlns="">
                    <test-string/>
                </test>
            </xf:instance>

        </xf:model>

    </head>
</html>

Finian

This seems related to when I try and fix the Serializer in issue https://github.com/eXist-db/exist/issues/1724#issuecomment-365451761

Adam,
Reading through issue #1724, I see you got different results for that problem between the Java Admin Client and Exide 2.4.3.

Running the anomalous XQuery for this problem gives the same result in Exide 2.4.2, the Java Admin Client and Oxygen 19.1 using XML RPC.

Finian

@finianoboyle Yes I got different results, because different serializers were involved. I still suspect a serialization issue here though

Hi,

I encountered the same issue with the transform:transform() function on exist-4.0.

It seems BaseX also reported a similar issue (see https://stackoverflow.com/questions/32132978/xquery-how-to-set-default-namespace-with-a-computed-namespace-constructor)
Is this related to SAXON update in eXist-3.6.1?

I tried to found a work-around in adding a default namespace to my XML documents and changing conf.xml file like this:

<transformer class="net.sf.saxon.TransformerFactoryImpl" caching="yes">
<attribute name="http://saxon.sf.net/feature/version-warning" value="false" type="boolean"/>
<attribute name="http://saxon.sf.net/feature/suppressXsltNamespaceCheck" value="true" type="boolean"/>
</transformer>

Regards,
Franck

In the stacktrace I do not see any hints towards Saxon; unless there are more traces than included in this ticket?

This is documented: https://saxonica.plan.io/issues/3068

Just need to update Saxon to at least 9.7.0.15. I've tried replacing 9.7.0.7 with 9.7.0.15 but that in itself did not work unfortunately contrary to an earlier message it did. Apparently there's more to updating that jar than just replacing it.

Error still present in v4.2.1 as released.

Error still present in v5.0.0 RC1 as released.

confirmed on 5.0.0-SNAPSHOT-dc35967f5

I also tested the code from the original post on Saxon 9.8.0.8 under Oxygen and found no issue. Since eXist-db 5.0.0 RC1 comes with Saxon 9.8.0.12, unless there's regression, the problem would be specific to eXist-db.

@duncdrum Confirmed fixed (contrary to what I found) or confirmed still an issue (as I found)? How does RC1 relate to SNAPSHOT-dc35967f5?

@ahenket confirmed still an issues (hence reopening the ticket). The snapshot build is slightly more recent than the RC1 build, based on the developbranch

Frankly, I m not yet sure whats going on…

Still an issue in tonight's build...

Does not look like a Saxon issue to me, since replacing @finianoboyle 's:

let $output := transform:transform($xml, $xslt, ())

let $package:=
<package>
{$output}
</package>

return $package

with simply:
return transform:transform($xml, $xslt, ())
works fine.

Another finding, which I hope may be useful in finding the cause (and at least is a workaround): storing the transform results in the database, then retrieving and wrapping those in <package> works fine.

let $output := transform:transform($xml, $xslt, ())
let $do := xmldb:store('/db', 'output.xml', $output)
let $output-in-db := doc('/db/output.xml')

let $package:=
<package>
{$output-in-db}
</package>

return $package

Okay so looking into this, the following query works fine on eXist-db develop HEAD:

<package>
    <unprefixed xmlns="http://default-namespace">
        <prefixed:element xmlns:prefixed="http://prefixed-namespace">
            <dummy xmlns=""/>
        </prefixed:element>
    </unprefixed>
</package>

This query also works fine:

let $xml := <anything/>
let $xslt :=
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="#all" version="2.0">
        <xsl:template match="/">
            <unprefixed xmlns="http://default-namespace">
                <prefixed:element xmlns:prefixed="http://prefixed-namespace">
                    <dummy xmlns=""/>
                </prefixed:element>
            </unprefixed>
        </xsl:template>
    </xsl:stylesheet>
return
    transform:transform($xml, $xslt, ())

However this query causes an error err:XQDY0102:

let $xml := <anything/>
let $xslt := 
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="#all" version="2.0">
        <xsl:template match="/">
            <unprefixed xmlns="http://default-namespace">
            <prefixed:element xmlns:prefixed="http://prefixed-namespace">
                    <dummy xmlns=""/>
                </prefixed:element>
            </unprefixed>
        </xsl:template>
    </xsl:stylesheet>
return
    <package>{transform:transform($xml, $xslt, ())}</package>

Reduction

So after a bit of fiddling about we can actually reduce the test-case. The problem is not related to Saxon (or parse-xml) but rather to do with how DOM's are merged. I have the following test cases:

  1. The correct behaviour case:
    xquery <x><dummy xmlns=''/></x>
  2. The error case:
    xquery <x>{parse-xml("<dummy xmlns=''/>")}</x>

Right

Op di 3 jul. 2018 12:55 schreef Adam Retter notifications@github.com:

Okay so looking into this, the following query works fine on eXist-db
develop HEAD:







This query also works fine:

let $xml := let $xslt :=








return
transform:transform($xml, $xslt, ())

However this query causes an error:

let $xml := let $xslt :=








return
{transform:transform($xml, $xslt, ())}

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/eXist-db/exist/issues/1682#issuecomment-402108184,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGJoiRpXxS96g0kQn7u-Z10RdFwk7bNpks5uC02DgaJpZM4RalaE
.

@adamretter Confirmed fixed, also in our own code. Thanks! (cc: @ahenket)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

opax picture opax  Â·  3Comments

cmil picture cmil  Â·  3Comments

Bpolitycki picture Bpolitycki  Â·  4Comments

ahenket picture ahenket  Â·  4Comments

joewiz picture joewiz  Â·  3Comments