> > I will download 8.2 and try it as well.
>
> 8.2 works 'out of the box' on the simple nested modules in my
> previous email,
> but I cannot get it to run the 'real' XQuery's, as it is
> reporting some strange
> errors. For example, running one test on Saxon 8.1.1 without
> passing params
> generates the expected error:
>
> Error at xsl:variable on line 11 of file:/C:/test/test.xq:
> XT0050: No value supplied for required parameter $pathInfo
>
> but with 8.2 I get:
>
> file:/C:/saxon/test/test.xq in #...
> "../common.xq"; declare#:
> Required item type of value of variable $1818 is
> xs:string; supplied value
> has item type attribute()
> Failed to compile query: XQuery syntax error
Saxon 8.2 is doing more compile-time checking than 8.1.1.
Also, Saxon now implements the strict type-checking demanded by the XQuery
specification for variables. In previous releases Saxon interpreted
let $anOptionValue as xs:string := $theOptions[$idx]/@value
according to the XSLT rules for xsl:variable, which cause the attribute node
on the right to be automatically atomized to produce a string. XQuery
(despite my best attempts to get it changed) doesn't allow this, you have to
do the atomization yourself by calling the data() function, and having
failed to get the rules changed, I implemented them in 8.2 as written.
>
> which after some debugging turned out to be a problem in the
> following function:
>
> declare function scf:bldSelectOptions($theOptions as element() *,
> $theSelectedOption as xs:string) as element() *
> {
> for $idx in 1 to fn:count($theOptions)
> let $anOptionValue as xs:string := $theOptions[$idx]/@value
> let $anOptionDesc as xs:string :=
> $theOptions[$idx]/@description
> return
> if ($anOptionValue = $theSelectedOption)
> then <option selected="selected" value="{
> $anOptionValue }">{
> $anOptionDesc }</option>
> else <option value="{ $anOptionValue }">{
> $anOptionDesc }</option>
>
> };
>
> which has the variables $anOptionValue and $anOptionDesc
> mistyped, but why
> didn't Saxon identify them correctly?
I'll look into this. Somehow, the original source name of the variable isn't
available to the code that detects the error, so it identifies it by an
internal code instead.
>
> Note that I've downloaded and installed the unbundled JAXP
> 1.3 in the endorsed
> lib as instructed. In addition the javax.xml.namespace.QName
> class is required
> which is available in j2ee.jar (or in my case
> geronimo-spec-j2ee-1.4-rc3.jar).
You don't actually have to put the JAXP classes into the endorsed lib, the
only requirement is that they're on your classpath.
>
> After fixing the above problem I run into :
>
> java.lang.NoSuchMethodError:
> javax.xml.parsers.SAXParserFactory.getSchema()
>
> which is because getSchema() is a v1.5 specific addition to
> the SAXParserFactory.
javax.xml.namespace.QName and the revised javax.xml.parsers.SAXParserFactory
are both in the jaxp-api.jar archive, which you should have on your
classpath. These errors suggest that jaxp-api.jar isn't being picked up.
Michael Kay
http://www.saxonica.com/
|