Decouple @odk/xpath API from XML/browser DOM

[eyelidlessness]

I'd like to explore the possibility of decoupling the @odk/xpath API from the XML/browser DOM API. Specifically for the purposes of this issue, the decoupling would involve accepting a different type for contextNode with the following considerations:

• Provide a significantly more limited interface, restricted to only those semantics of a node which satisfy the implemented XPath semantics. This interface would likely still be "a DOM", in the sense of representing a traversable tree of nodes consistent with the XPath node types, but it wouldn't necessarily be "the DOM".

  A simpler interface would allow us to more easily reason about potentially substituting node implementations. And being able to more easily reason about this, we could better evaluate if and how to reap other potential benefits (discussed below).

  It's an open question whether this simpler interface should attempt to maximize compatibility with "the DOM" (i.e. so that an unmodified XML/browser DOM reference is assignable), but my gut instinct is that it should not be a requirement though it may be nice to have. If we pursue this, and choose not to maximize compatibility, we'd still have the option of providing a compatibility layer e.g. wrapping the underlying XML/browser DOM APIs.

• Minimize incidental complexities of different interfaces for different node types. This is a source of significant incidental complexity in the evaluation implementation as well, and it's highly error prone. A trivial example of this kind of incidental complexity is the lack of consistent, direct access to certain properties, such as ownerDocument. Another good example is the combinatory explosion if slightly different ways to access node data (textContent, innerText, children, childElements, data, value, ...).

• Require (whether enforced or not) certain guarantees which aren't assumed in the XML/browser DOM compatible API we currently provide. Top of mind here:

  • Require that the entire context is read-only for the entire scope of a given evaluation. This would unlock a wide variety of potential performance improvements without baking in a lot of domain-specific assumptions.

  • Require that evaluation is always performed against a context node which is fully intact/connected to its root. This would overlap both with API simplification and performance.

• Provide specific affordances for additional optimizations, e.g. the ability to designate certain aspects of a context tree permanently immutable.

• Make callable aspects of the API explicit, either by choosing to express them as methods rather than as property accessors, or by designating them as getters with a clear indication that they are anticipated to have an associated runtime behavior. In the most minimal version of this, it would help us reason about where certain accesses are more expensive than others.

  In a broader vision, this would allow us to provide a reactive implementation of nodes, e.g. allowing a reactive graph of dependencies to be established automatically as they're accessed while evaluating an expression referencing them. This in turn could potentially allow for other valuable use cases, such as producing an evaluation history log which can be referenced directly back to e.g. instance nodes—both valuable for direct debugging, as well as potentially enriching bug reports from users.