3.5.0

New features

• Pass buckets from FontoXPath to the outside when requesting dom relations through the domFacade.

This can be used to determine the intent of the XPath engine when traversing certain dom relations so that an external system (such as Fonto) can determine more specific dependencies.

Fixed issues

• Make the prefix/namespaceURI of the internal element and attribute types nullable. This makes interoperation with DOM implementations easier.

3.4.2

Fixed issues

• Comparing xs:untypedAtomic with an xs:date did not always work
• Local functions were not in scope for dynamic function lookups

New features

• Experimental, subject to change: add the currentContext option as a way to pass through data from evaluateXPath to javascript context.

3.4.1

Updated packages to newer versions.

Optimized queries which use the descendant axis in an outermost() function. See usesHints.tests.ts for examples.

3.4.0

Features

The following XQuery functions have been implemented:

• fn:function-lookup
• fn:function-name
• fn:translate
• fn:codepoints-to-string
• fn:string-to-codepoints
• fn:codepoint-equal

Fixed issues

• A compiled IDomFacade was passed to custom XPath functions which had minified method names.

3.3.0

Features

The following XQuery functions have been implemented:

• fn:has-children
• fn:path

3.2.2

##Fixed issues:

Improve the TypeScript typings of the domFacade that can be passed to FontoXPath.
Fix bugs related to empty function bodies (#74)

3.2.0

(Optional) Stack Traces

Features:

FontoXPath can output a basic trace for an error if the debug
option is set to true. This is disabled by default because of
performance reasons.

evaluateXPathToBoolean(`
if (true()) then
  zero-or-one((1, 2))
else
  (1, 2, 3)
`, null, null, null, {debugMode: true});

// Throws:
1: if (true()) then
2:   zero-or-one((1, 2))
     ^^^^^^^^^^^^^^^^^^^
3: else
4:   (1, 2, 3)

Error: FORG0003: The argument passed to fn:zero-or-one contained more than one item.
  at <functionCallExpr>:2:3 - 2:22
  at <ifThenElseExpr>:1:1 - 4:12

Fixed issues

• The options had a required property which was not defaulted properly.

3.1.0

Additional XQuery update facility expressions

We have moved to TypeScript in this version, for this we also ship a fontoxpath.d.ts containing the types for the public API.

Features:

• Computed attribute constructor
• Computed element constructor
• Copy modify expression
• Delete expression
• Insert expression
• Rename expression

Note: the use of XQuery Update Facility 3.0 is in preview and subject to change.

Fixed issues

• Javascript objects passed through variables could only be read once.

3.0.0

XQuery upgrade facility

Breaking changes:

Correct XPath reverse axes

Problem

Previous versions have an issue with reverse axes: the ancestor,ancestor-or-self, preceding and preceding-sibling axes sometimes mistakenly returned their results in reverse document order. This has been fixed, but editors may accidentally depend on the old behavior. The error only occurred with XPath queries (or partial XPath
queries) which only contained a single step: like ancestor-or-self::* or preceding-sibling::div[@class="something"]. These XPaths used to result in a sequence containing the matching nodes, but in reverse document order. That same applies for expressions like evaluateXPathToFirstNode('ancestor-or-self::*)[1]'): this used to return the closest element ancestor of the context node. This same XPath now returns first element node in document order, which is usually the document element.

Note that XPaths with multiple steps were not affected by this bug. XPaths with the form (ancestor::div/parent::*)[1] correctly resulted in the parent of the first div, in document order: the 'topmost' one. Even XPaths as simple as ./preceding-sibling::* circumvented the bug. Also, predicates (what's between the []
brackets) are always evaluated in the order of the local step: preceding-sibling::*[1] will always return the closest sibling.

Fix

Since only XPaths with reverse axis steps are affected, a search for the reverse axis step names (ancestor, ancestor-or-self, preceding and preceding-sibling) will give you the full list of possibly affected XPaths. Secondly, since only single-step XPaths are affected, XPaths with a / on either side of the "step" can safely be
ignored. Thirdly, since only the order is changed, all XPaths which disregard order can also be ignored. This includes XPaths like count(ancestor::*).

The fix is usually as simple as adding a [last()] filter at some point of the expression:

// Expressions like:
evaluateXPathToFirstNode('ancestor-or-self::div', node, readOnlyBlueprint);
 // Should be rewritten to:
evaluateXPathToFirstNode('ancestor-or-self::div[1]', node, readOnlyBlueprint);

3.0.0-alpha.0

This is a prerelease to integrate the new compiler