A simple XPath evaluator abstraction.
A simple XPath evaluator abstraction. It has no knowledge about static and dynamic contexts (other than the optional context item), etc. It also has no knowledge about specific implementations, such as Saxon. Moreover, it has no knowledge about XPath versions.
This trait looks a bit like the JAXP XPath
interface. Like the XPath
interface, this trait does not support the
XDM data types that succeeded XPath 1.0. Compared to the JAXP XPath
interface this trait is more Scala-esque and type-safe.
A simple XPath evaluator factory abstraction.
A simple XPath evaluator factory abstraction. The implementation may or may not be thread-safe.
Yaidom XPath API implementation for Saxon, using the JAXP XPath API underneath.
Yaidom XPath API implementation for Saxon, using the JAXP XPath API underneath. This XPath implementation supports XPath 3.1.
XPath evaluation abstraction. It is for yaidom what the standard Java XPath API is for Java. Like the standard Java XPath API, this yaidom XPath API is abstract in the sense that it allows for many different implementations. This yaidom XPath API has even an implementation targeting Scala-JS, so it has no dependencies on JAXP.
This API should be useful for any XPath version, even as old as 1.0. Indeed, there is no XDM (XPath Data Model) abstraction in this API.
Preferably implementations use (the same) yaidom element types for context items and returned nodes, or use types for them that have yaidom wrappers. This would make it easy to mix XPath evaluations with yaidom queries, at reasonably low runtime costs.
Currently there are no classes in this XPath API for functions, function resolvers and variable resolvers.
The remainder of yaidom has no dependency on this
xpath
package and its sub-packages.Implementing XPath support is error-prone. This is yet another reason why it is important that the remainder of yaidom does not depend on its XPath support!