Saxon » SaxonJS

The proposed solution is that we should throw an error if we ever attempt to get a property of null or undefined. This is indeed what happens in JavaScript. So if at any point prior to the last step, while stepping down a chain of nested properties, we encounter null or undefined as the property value, then we should in fact throw an error.

However it would then be inconsistent not to throw an error if the initial object is null or undefined; i.e. ixsl:get($object, 'prop') should throw an error if $object is null or undefined. This would be a change in behaviour for Saxon-JS, which could potentially cause problems from unexpected errors in existing applications.

Note that we did previously look into what to do in this case (see Bug #3501: Error when object supplied to ixsl:get() is null), but it now seems that that solution was not fully thought through. At that time we decided that it would make sense for ixsl:get($object, 'prop') to return the empty sequence when $object is null; so that we get the same result as when using the lookup operator: $object?prop. Note that by the XPath specification, ()?prop always returns the empty sequence.

However, we subsequently clarified that ixsl:get($object, 'prop') and $object?prop are not always equivalent; see https://www.saxonica.com/saxon-js/documentation/index.html#!development/properties:

In order to use this $object?propName shorthand, the JavaScript object must be converted using "weak" conversion (as described in JavaScript to XDM Conversion), and must not be of a more specific type which is recognised (i.e. the object is not any of the following: null, undefined, String, Number, Boolean, Date, Node, Array, or Function). So that $object is treated as a JSValue wrapped external object.

And this specifically points out that you may not get the same result for null or undefined objects!

If we amend the definition of ixsl:get() to say that the supplied object must exist (i.e. not be null or undefined in JavaScript), then this brings the function better in line with ixsl:call, ixsl:contains() and ixsl:set-property, for which we already specify that the supplied object must exist. We should update the function signature to reflect this to provide the correct cardinality check - which means a change in IXSLFunctionSet.java for Saxon on Java, and in lib/xpath/xsltData.js for the XX compiler.

Committed:

• Saxon-JS code changes (in ExtraFn.js and lib/xpath/xsltData.js)
• New selenium browser tests: ixsl/get20; ixsl2/getlookup20, getlookup20b
• Updated results for tests ixsl/getEmpty01, getEmpty02, getEmpty04

These now all align with the proposed solution above.

I have not yet done the following:

• Commit update to IXSLFunctionSet.java for Saxon on Java
• Documentation updates