xpath currently works on Node trees only — xpath(::LazyNode, …) is a MethodError. This surfaced in tecosaur/RestClient.jl#11: REST-API extensions parse with the lazy reader, and running a path query today means eagerly materialising the whole response first.
Sketch of what it would take: the evaluator (src/xpath.jl) is written against Vector{Node{S}} contexts, but almost every step only needs child iteration plus tag/attribute access, which LazyNode provides too (an element-only iterator — #78 — would be the natural shared primitive for the name and * steps). The parent axis (..) is not a blocker either: Node has no parent pointers, so the current implementation already re-walks from the root (_find_parent), and LazyNode can do the same. So it's mostly generalising the evaluator's signatures over the two readers and keeping their semantics aligned.
Not urgent — filing it as a candidate improvement, probably v0.5 material alongside the other structural items.
xpathcurrently works onNodetrees only —xpath(::LazyNode, …)is aMethodError. This surfaced in tecosaur/RestClient.jl#11: REST-API extensions parse with the lazy reader, and running a path query today means eagerly materialising the whole response first.Sketch of what it would take: the evaluator (
src/xpath.jl) is written againstVector{Node{S}}contexts, but almost every step only needs child iteration plus tag/attribute access, whichLazyNodeprovides too (an element-only iterator — #78 — would be the natural shared primitive for thenameand*steps). The parent axis (..) is not a blocker either:Nodehas no parent pointers, so the current implementation already re-walks from the root (_find_parent), andLazyNodecan do the same. So it's mostly generalising the evaluator's signatures over the two readers and keeping their semantics aligned.Not urgent — filing it as a candidate improvement, probably v0.5 material alongside the other structural items.