Bug #2749
closed
Type error XPTY0004: Required item type of first argument of collection() is node(); supplied value has item type xs:base64Binary
Category:
XPath conformance
Fix Committed on Branch:
9.7, trunk
Fixed in Maintenance Release:
Description
Reported by user:
I presumed no config was necessary, because per http://www.saxonica.com/documentation/index.html#!sourcedocs/collections "the URIs listed in the doc elements are treated like URIs passed to the doc() function" and in the test XSL, doc-available() succeeds with the same url immediately before collection().
Anyway, I tried -config of the mappings from "rdf" to "text/xml". The same error. The test files are attached.
P:\test>java -classpath saxon9ee.jar net.sf.saxon.Transform -config:config.xml -it:main -t -xsl:test.xsl
Saxon-EE 9.7.0.5J from Saxonica
Java version 1.8.0_91
...
Type error
XPTY0004: Required item type of first argument of collection() is node(); supplied value
has item type xs:base64Binary
Required item type of first argument of collection() is node(); supplied value has item type xs:base64Binary
- Status changed from New to Resolved
- Applies to branch 9.8 added
- Fix Committed on Branch 9.7, 9.8 added
The problem is content types not known by the AbstractResourceCollection are assumed to be binary. The fix was to add the rdf+xml to the map of known resources (i.e. resourceFactoryMapping in the AbstractResourceCollection).
Bug fixed and committed to svn on the 9.7 and 9.8 branches.
It seems like setting the resource fileExtension mapping in the config file does not take effect:
<configuration edition="EE" xmlns="http://saxon.sf.net/ns/configuration">
<global expandAttributeDefaults="false" validationComments="true" />
<xslt recoveryPolicy="doNotRecover" />
<serialization saxon:indent-spaces="4" xmlns:saxon="http://saxon.sf.net/" />
<resources>
<fileExtension extension="rdf" mediaType="application/xml" />
</resources>
</configuration>
Opening this as a new bug. see #2750
- Status changed from Resolved to In Progress
Reopening this bug issue because we need to investigate the poor diagnostics.
- Status changed from In Progress to Resolved
The bad error message appears to arise as follows.
In CollectionFn line 201, if the XPath version is 3.0 or less (i.e. not 3.1), the collection() function is required to return a sequence of nodes. So we add an item checker to ensure that this is the case. But the RoleDiagnostic (which determines the error message) is set up to report that the error relates to the first argument.
If we're not going to allow items other than nodes to be returned, then perhaps the CollectionFinder shouldn't even consider the possibility, and should parse everything as XML. But the immediate thing is to fix the error message, which I have done.
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.6 added
Bug fixed in maintenance release 9.7.0.6.
- Status changed from Closed to In Progress
Reopened by user:
(a) What about files having no file extension?
(b) The diagnostics have not been improved: we still get
XPTY0004: Required item type of result of call to collection is node(); supplied value has
item type xs:base64Binary
- Related to Bug #2881: Required item type of first argument of collection() is node(); supplied value has item type xs:base64Binary - no file extension added
- Status changed from In Progress to Closed
- Fix Committed on Branch trunk added
- Fix Committed on Branch deleted (
9.8)
- Applies to branch deleted (
9.8)
Please register to edit this issue
Also available in: Atom
PDF
.