Upgrade from 7.4 to 7.5
Recompile your schema
Fonto 7.5.0 fixes an issue with its schema compiler: schemata containing an element with an
xs:any were not correctly compiled. This occurred in the schema for MathML for instance. To prevent future issues, we require you to recompile your schema. This can be done using the FontoXML Development Tools with the command
fdt editor schema compile.
XPath reverse axes
We have upgraded our dependency on FontoXPath to 3.0.0. This version fixes an issue with reversed axes i.e. the
preceding-sibling axes sometimes mistakenly returned their results in reverse document order. Editors may (accidentally) depend on this specific order. The issue occurred for (partial) XPath queries which contained a single step e.g.
preceding-sibling::div[@class="something"]. These queries used to result in a sequence containing the matching nodes in reverse document order instead of document order.
The same applies to expressions such as
evaluate. This expression used to return the closest element ancestor of the context node, usually its parent element, whereas it will now return the first element ancestor in document order, usually the document element. Note that queries with multiple steps were unaffected by this issue. Queries such as
(ancestor::div/parent::*) correctly resulted in the parent of the first div in document order i.e. the topmost one. Predicates (the expression between the
 brackets) are always evaluated in the order of the local step i.e.
preceding-sibling::* always returns the closest preceding sibling.
Firstly, since only XPath queries with reverse axis steps were affected, a search for the reverse axis step names
preceding-sibling will give you a full list of potentially affected queries. Secondly, since only single step queries were affected, queries with a
/ on either side of the step can be safely ignored. Thirdly, since only the order was reversed, all queries which disregard order can also be ignored. This includes queries like
Note that queries evaluating to booleans were also unaffected i.e. the behavior of
evaluate is unchanged. The same applies to parameters of type X
selection parameter of set
x parameter of set
The fix is usually as simple as adding a
 filter to the expression:
// Expressions like: evaluateXPathToFirstNode('ancestor-or-self::div', node, readOnlyBlueprint) // Should be rewritten to: evaluateXPathToFirstNode('ancestor-or-self::div', node, readOnlyBlueprint)